Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
- Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 18 Jun 2001 10:23:56 -0400
OK, folks, this is it... I don't think this thread is going much of
anywhere useful. I have my opinions, others have theirs, none of us
seem to be changing 'em more than in an incremental fashion and we are
all likely boring the heck out of the rest of you.... This'll be my last
post in this thread (yes, the rest of you can have the last word :-).
Of course, given Mail.app's new filtering features, we've likely already
made it into the killfilter of a lot of people as it is...
This contains combined replies to several folks.
---
On Saturday, June 16, 2001, at 03:11 AM, Christopher Lloyd wrote:
At 08:54 AM 6/15/2001 -0400, bbum wrote:
On Friday, June 15, 2001, at 12:03 AM, Christopher Lloyd wrote:
So why would Apple help maintain and release Darwin/x86 ? Doesn't
sell hardware, doesn't even sell Apple software.
The should be pretty obvious;
It is and it doesn't fit into your sweeping statement that Apple is
this focused for-profit machine in the consumer and education market.
Part of making a buck is to pour some $$$ into marketing and PR. In
this case, Apple is milking the PR value of the open source movement.
But it isn't just a PR stunt, they have also set up a compelling
operating system project within the BSD community such that there are
lots of folks participating because they see value in the free side of
the OS. This has contributed greatly to the quality of OS X (and OS X
Server 2.x). Given that the kernel, the BSD layer, etc.. are key to an
OS X box actually booting and operating in a stable fashion, there is a
lot of technical value in the Darwin project.
The Intel part of the port has had almost no resources dumped at it on
the part of Apple. Most of the folks working with Darwin/Intel have
been doing so on their own time.
- to keep options open
EOF/ObjC doesn't do that?
Darwin/Intel ensures that the low-level parts of Mac OS X will boot and
operate on machines with a different endianess than PPC. More
importantly, Darwin/Intel has consumed *very few* resources.
EOF/ObjC requires *a lot* of resources to duplicate features already
taken care of by EOF/Java and it would benefit a relatively small
segment of the development community; the handful of developers that
want to build Cocoa based applications using EOF that are unwilling to
use Java.
(resources required: Fixing/maintaining the EO Palette-- likely a lot
more broken than just patching a single palette...
fixing/maintaining/building native EO adaptors against client libraries
that don't exist on the platform.)
- to take advantage of the value of open source both in a
marketing and community sense
So why not release EOF/ObjC as an open source project, because, in your
own words ...
Because the internal implementation-- the APIs, algorithms, etc..-- are
still considered a strategic advantage regardless of language and Apple
perceives that open sourcing EOF/ObjC would dilute that advantage?
There may also be legal reasons-- the implementation may be encumbered
with licensing issues.
There may also be quality issues-- the implementation may leverage
internal API on the Foundation that Apple is not ready or does not want
to expose.
How does WOF fit into your statements? From Apple's product
description: "WebObjects allows you to focus on only that code needed
for your e-commerce, asset management, or MIS solution", yea, that
sounds like the consumer&education market. WOF is an enterprise
product, no question.
Yup; WOF is an enterprise solution, always has been and, likely,
always will be. Most importantly, it is the enterprise solution that
Apple has built a huge part of their business operations on top of.
Everything from product registrations to the apple store to iTools to
the apps used to check folks in at WWDC are built with WO.
They don't need to keep it as a product to do this. As a product it
doesn't fit into their strategy according to you, was a massive
resource suck to rewrite in Java and remains an also-ran product. I'm
not advocating they drop it, but it flies in the face of your "Apple is
a for profit company building hardware that is largely aimed at the
consumer and education markets".
You are exactly right. However, there is a tremendous amount of value
coming out of the development efforts of the WO team and the results do
generate some revenue; i.e. may generate enough revenue to mostly cover
cost of development. The product does provide some amount of good PR,
though Apple certainly hasn't leveraged it.
Most importantly, it keeps options open. The Java/EO implementation
means that they continue to have first class (though some believe
otherwise just because of the "Java" part) n-tier application
construction tools and that provides a lot of value both inside and
externally to Apple.
Likely, the internal use of WO combined with the marketing value--
which, obviously, they haven't really leveraged-- of remaining a
solutions provider in the Web space is the only thing keeping
WebObjects alive.
Not very encouraging words for WebObjects. Prepare to jump onto the
next bandwagon!
Heh. I wouldn't exactly consider WO a bandwagon. If I were into
jumping onto bandwagons, I would have been banging my head against
EJB/JSP/J2EE over the last 2 years.
You are doing one thing "CodeFab provides a wide range of system
integration and consulting solutions, focused on developing and
deploying enterprise scaled object-oriented solutions for large
corporations. " And saying another.
(Speaking for CodeFab for only a moment-- the rest of this has been
purely personal....)
Hardly; CodeFab uses many technologies and many languages.
Do as you say not as you do? Writing enterprise software using Apple
enterprise technology, advocating that Apple is a consumer and
education focused company and lambasting those who depended on Apple to
deliver enterprise(and desktop) software. It is just convenient that
Apple dropped technology you don't depend on.
It wasn't entirely convenient; Apple has been spouting Java, Java,
Java!!! for WebObjects since before WWDC/2000. Combine that with the
demands for integration with numerous third party tools/APIs that were
generally only available as Java and it became rather imperative that we
focus our WO development efforts against the Java APIs.
Given the state of the EOAdaptors and that fixing 'em is largely out of
Apple's hands, it has been clear for some time that something would have
to be done to EO to address this issue. JDBC is an obvious solution.
As far as Yellow/Windows was concerned, it was clear 2+ years ago that
the amount of effort that would be required to fix the Yellow/Windows
environment such that it achieved parity with the OSX/Cocoa/Quartz world
would be huge and very expensive. It would require ripping out
display postscript for both technical and legal reasons and this
fundamentally changes the model on Yellow/Windows. Worse, these
resources would have to be sucked away from OS X at a time when OS X was
already behind schedule and was clearly the most critical development
effort on Apple's plate.
I'm not lambasting anyone for depending on the enterprise/desktop APIs
on Yellow/Windows or provided by ObjC/EOF. I feel your pain-- I have
had APIs ripped out from under my products and it sucks!
[... <snip> a great history of CodeFab and their strategic
choices ...]
Why do you justify Apple's position? Is it some great reaffirmation
that CodeFab is doing the right thing ? That everyone who trusted Apple
about YB/Windows and EOF/ObjC are idiots who deserve to crash&burn? I
don't
get it. Yea, you can justify anything, but that doesn't stop reality,
and reality is that Apple is burning bridges.
I am trying to convey the message that EOF/ObjC is end of life'd for a
variety of reasons that are more valid than "Apple is trying to screw
its customers". ....that EOF/Java is a lot more viable and pleasant
to work with than a lot of folks have assumed.
Apple is burning bridges while it builds new bridges. That is the
fallout from merging two companies and from setting business direction
of a large company; bridges will be burned.
Frankly, we would rather build desktop applications, have the skills
necessary for doing so, and are actively investigating whether or not
a market exists for such skills.
What's the matter? Java not up to the task? Apple's "consumer and
education markets" a scary place ? It's always easier to take the
consulting route because there are always projects that need to be done
and you typically don't have a long API commitment. It's much harder to
stick with API's and Apple/NeXT makes it more difficult than it should
be. I can't blame you for not doing applications on Apple technology!
Let me clarify.
"would rather" means we would prefer to be building desktop applications
regardless of language. I have done Cocoa development in both ObjC and
Java, they both work and-- frankly-- they are nearly equal in capability
for a lot of tasks.
It is a matter of finding folks willing to pay $$$ to have a third party
build applications explicitly targeted to the OS X platform. This is
quite a bit different than finding folks to pay for the development of
applications targeted to any platform on the client side while being
served from Solaris (or 2K / OS X Server-- but we generally use Solaris).
In terms of API commitment, you are correct in that we don't-- yet--
have the 5+ year API commitment of a shrink wrap product, but we do have
long term commitment in that we generally don't focus on short term
projects. Most of our clients have been or will be with us for quite
some time. We migrate clients across releases of WO-- including
porting a client from ObjC to Java on the 4.x platform in preparation to
a move to 5.x.
By staying focused on what contributes value to that platform--
even when it means screwing over developers that have latched on to
technologies that no longer make sense or that have become unbearably
expensive to maintain-- they have continued to increase profitability
and market share. I.e. they have continued to generally increase the
value of Apple Computer, Inc.
All of the Java and Objective-C technology changes have little or
nothing to do with Apple's recent upswing. They've managed to regain
their foothold in hardware and have some good MacOS based apps. It will
be a while before anyone can comment on whether Cocoa, Carbon, WOF or
anything else proves to pull Apple up. They are dropping EOF/ObjC
before it has even had a chance to move.
And replacing it with a viable alternative; EOF/Java.
----
A couple of people have conjectured that building a JDBC adaptor that
speaks across the bridge to ObjC/EOF would be a viable solution.
It might very well be, but there are some significant engineering
challenges. Namely, pushing the bridge down to that level will incur a
massive performance penalty unless the bridge could be pushed into the
middle of the EOAdaptor-- i.e. such that the snapshots are pure ObjC,
but the Snapshot<->DBConnection piece was bridged. This would be hard,
but would certainly be an interesting project.
The end result would still be a duplication of APIs and all of the
maintenance issues that would incur; this is not the same duplication
seen in Cocoa/Java because Java/EOF is also targeted to pure Java, cross
platform environments like Swing. That would be very expensive and
Apple would likely not be able to justify that expense given that
EOF/Java can do everything that EOF/ObjC can.
It would help support those that want to port from EOF/ObjC to EOF/Java,
but it sounds like most of the folks in the EOF/ObjC camp want to stay
there and Apple would likely face this same issue again in a couple of
years when they really wanted to end-of-life EOF/ObjC.
---
Deirdre said:
// I disagree that it's only marginally btter than Java. Java is nothing
but C++ with training wheels. And C++ isn't
// that great a language. If I'm going to use a C++ like language, I
want to use C++, not a wannabe for sloppy
// programmers who can't think with pointers.
Yeah, and ObJC is nothing more than C with a few fancy structures that
let you do objects. And Python is nothing more than a bunch of fancy
dictionary lookup behavior. And C is just a fancy macro assembler.
And perl is just a line noise interpreter. And Lisp is just a fancy
language for making sure your () keys get exercised.
Java, ObjC, Python and all the rest have their advantages and
disadvantages. Some more than others.
---
On Friday, June 15, 2001, at 04:27 PM, Jeff Szuhay wrote:
Where's the strategic advantage for Apple to sell more OS X boxes
if a product written in Java can be easily ported elsehwere? After all,
Apple is a _hardware_ company, is it not?
Cocoa based apps cannot be easily ported elsewhere and they provide a
much richer UI experience than Swing. The persistency layers, on the
other hand, can be easily ported [if against Java/EO] and can be used to
solve persistency for both desktop and web targeted applications.
It is similar to QuickTime.... it works on Windows [i.e. Swing], it
works better on Mac OS X [Swing, but with Aqua widgets], but the
creation tools are 10x better on OS X. Similar, but not identical, in
that a Cocoa UI will be 10x better than Swing, both running on X.
(10x is just a marketing number... it isn't any kind of a real metric)
---
On Friday, June 15, 2001, at 04:51 PM, Scott Anguish wrote:
We're NOT talking about "market realities" here.. That isn't why
Obj-C/EOF isn't working right now.
It's because Apple refuses to fix a single broken palette, thereby
keeping their commitment to EOF/Obj-C that they made less than six
months ago.
Do you know for a fact that it is a single broken palette? ... that
there isn't something broken deeper in the core due to all of the
changes between versions of IB or versions of the AppKit?
An Apple engineer indicated in this forum that it is more than just the
palette that is broken.
Even with the palette fixed, the usefulness of EO/ObjC will diminish
rapidly unless the EOAdaptors are largely revisited or completely
rewritten. We are already 2 or 3 versions behind on the Oracle front--
missing some fairly key features-- and the Sybase support is basically
non-existent. OpenBase and FrontBase are first class, but that'd be
the limit of first class database support on the platform. Even if
Apple were to decide to throw a ton of money at the problem, they still
have to convince the database vendors to provide the bits o' proprietary
knowledge necessary to build/rebuild the adaptor.
You're not aware of the size and scope of the project at Rockwell
I guess..
Correct-- I'm also not aware of a whole bunch of other projects that I
have been very careful not to mention or consider during the course of
this argument due to NDA issues....
---
That's that. I'm done. Have code to write; ObjC, Python, and Java,
thanks. Some of it is available from mosxland.sourceforge.net --
including a Java/Cocoa project (but not Java/Cocoa/EOF, yet) that is a
total work in progress....
( It has been an extremely thought provoking thread and I have nothing
but respect for all of you who so strongly disagreed. Who is right?
Who knows-- only time will tell... and, in some cases, even time won't
give the answers. )
b.bum