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: Wed, 13 Jun 2001 18:10:25 -0400
Jeff/Deirdre,
Your needs are your needs and they are not the needs of the average
developer! The fact that you have quite effectively and capably dealt
with databases involving millions of records per table and requiring 15+
page SQL statements using 23-way joins is damned impressive....
.... and completely outside of the realm of the needs of an average
developer!
The whole point of this discussion is the use of Cocoa/EOF for
non-enterprise applications with the always present relgious tinge of
ObjC vs. Java.
The reality is that MOST developers don't need the level of power
and customization that you need.
Personal Example:
In the nearly 12 years that I have been doing work against various
NeXT APIs and, more specifically, have been using various
Object<->Relational mapping solutions (FireHouse [bet no one remembers
THAT], dbkit 1.x, dbkit 2.x, OPP [Object Persistence Paradigm from
OTI-- app is actually still in production, last I heard], EOF 1.x
through, what, 5.x now?... and a smattering of solutions in the EJB,
Perl, and Python spaces), I have only had to actually write hand tuned
SQL a handful of times-- most of those were with FireHouse or OPP, but
that was because of their intrinsic design patterns, not because of any
performance reasons.
Did the apps perform well?
Yes. They performed well enough that the client-- internal and
external, depending on situation-- was happy with the application(s),
felt comfortable with the scalability, and was confident that the
solution could be maintained beyond the required lifespan.
Could they have been faster through the use of hand tuned SQL?
Certainly; absolutely... 100% YES. But what would have been the
point? The client was much happier with me or my team spending our
time focused on delivering solutions to the problems they had, not
focused on optimizing code that was already performing well above
acceptable parameters!
In those situations where we did need to hand tune the SQL, it
wasn't a big deal. It was optimized-- typically by someone with
experience much more along the lines of Jeff's or Deirdre's than mine--
and life went on.
---
Am I happy about first class EOF/ObjC suport going away?
Not particularly, but I understand that it is a reality above and
beyond something that Apple can totally control. I also understand
that for my needs-- and for the needs of a very large part, if not most,
of the community-- the chosen direction is not only workable, is
actually quite pleasant to work within.
Apple can't control the database vendors; as such, there is no
guarantee that there will ever be first class native client libraries on
OS X. For that matter, there is a lot of reason why the database
vendors do NOT want to do anything to support EOF-- EOF makes their data
server into a [relatively] easily replaceable commodity. This is not
attractive to them.
Even if the client libraries are available, it requires a
significant amount of engineering to even maintain the EO adaptors, much
less extend them to track new features made available as new versions of
the client libraries are shipped. It is very expensive. It is time
consuming. Worse-- unless the database vendors are willing to work
tightly with Apple, the perception will *always* be that Apple is behind
the curve because there will *always* be a lag between the release of
the client library and the release of an updated and qualified EO
adaptor that takes advantage of the newly available features.
One of the huge advantages of the JDBC drivers is the JDBC API
itself and the qualification/certification program that the vendors are
compelled to actually comply with.
Example: Because of the JDBC specification and the rabid Java
market [rabid because you'd have to be insane to buy into some of the
crap some folks are selling within the market], Sybase and Oracle are
both compelled to create and release fully compliant JDBC drivers that
closely follow the latest releases of their data servers. The same
holds true for just about every other database vendor in the industry--
they make real sales as a result of having JDBC drivers and, as such,
have a real motivation to implement said drivers.
For my work-- and I suspect the same holds true for many on this
list-- this is a huge boon! It meant that when WO 5.x shipped, I could
go straight to sybase.com and oracle.com, grab the latest version of the
thin drivers, and be up and running against the latest versions of their
data servers within the day!
In the ObjC world, I am still stuck with an Oracle adaptor that is
optimized for Oracle 7.1.5 and a Sybase adaptor that was last compiled
something like 5 years ago..... and very few other choices (OpenBase and
FrontBase, obviously).
Having Apple release the adaptor doesn't really work-- it assumes
that adaptor was created in a fashion that the licensing would allow
this. I don't believe that was the case. Even if it were legally
possible, there are very few of us in the community that have the
knowledge to actually maintain and extend the adaptor over time. That a
handful of the developer community can-- and might even be willing to
share-- is laudable, but it doesn't provide a very reasonable foundation
upon which Apple could bulid a business.
Finally, it is very likely the case that Apple hasn't made a
conscious effort to remove or destroy support for things like the
EOPalette. It is far more likely that the sweeping changes required to
support Aqua in IB broke the EOPalette in a fashion that would require a
fairly monumental effort to fix. Given that fixing the EOPalette to
support OS X's IB still doesn't address the Windows IB problem and the
whole thing may be a wash if the database vendors decide to make it
impossible for Apple to create/ship EOAdaptors against their products
[setting aside the basic resource issue even if it IS possible], what is
the real return on investment for devoting a bunch of resources at
fixing the EOPalette? Likely, not nearly as much ROI as devoting those
same resources to pushing the Java Client / JavaEO / IB technologies
forward-- i.e. not as much as supporting the needs of what very likely
is the majority of the developers out there.
I have a lot more to say on this subject, but I'm not sure anyone
has made it this far and I have to get some real work done [in Java
against WO 4.5.1, at the moment... and a bit of 5.0 ...and a bit of
Java/Cocoa/EO. All meeting or exceeding requirements, thank you :-) ].
b.bum