Re: EOF replacement
Re: EOF replacement
- Subject: Re: EOF replacement
- From: Georg Tuparev <email@hidden>
- Date: Thu, 21 Feb 2002 15:35:58 +0100
On Thursday, February 21, 2002, at 12:26 , email@hidden wrote:
As someone who has actually seen NeXTSTEP running on IBM hardware and
followed and contributed to the technology for the past 12 years I am
very well aware of what it does mean to write a replacement for EOF.
Um... I've seen NeXTSTEP running on IBM hardware too; I worked on an
Intel box at NeXT. And I worked on WebObjects for years.
I mean on IBM workstation back at 1989 or 1990.
And I think if you're imagining writing EOF for Obj-C yourself, you're
in fantasy land. On the bright side, if you do succeed, you'll have a
product you can sell to other people for staggering sums of
money. :-> Of course, you'll have to be careful not to violate any
Apple patents...
I have been here several times. First my team had to write a version for
a subsidiary of Simens. It is still widely used for hospital information
systems for the German market. Simens did not want to depend on NeXT ...
as we know, a very wise decision. Additionally we wrote an SAP/R3
adaptor. Second, we wrote one very serious WO/OpenStep based system for
the German chemical company Henkel. There we made enhancements to EOF in
three direction: to cope with data warehouse star schema, to support
master (template) vs. concrete deployment EOModels, and last but not
least to support natively DB cursors. These additions turned to be
extremely useful, and these together with a build-in ability to cope
with two-phased commits is what I mean by talking about goodies.
The reason why I asked my question is the fact that Apple is fiddling
with the Foundation kit for some time now: key-value coding is now
part of it, methods like inverseForRelationshipKey are showing up,
EOClassDescription and EONull made it also into Foundation... This of
course helps the AppleScript integration and makes it possible to
integrate in a nice and consistent way other languages like Ruby or
Python. But this is a huge step towards persistency framework too. It
might also mean that Apple is already working on it too. Today it is
much easier to duplicate the old EOF functionality ... just think on
what Foundation was back in 1994!
Those little snippets of EOF functionality are trivial compared to
the bulk of EOF. Having those things provided for you in Foundation
will save you a week or three of work at most. And of course you're
assuming that the Foundation implementation of those things contains
everything you will need for your EOF clone, but really, it probably
doesn't. You'll probably have to implement your own key-value coding
so you can put the hooks and search order and such in it that you need,
for example. EOF's key-value coding is a very complicated affair. I
don't believe Foundation preserved all that complexity, although I
could be wrong, I haven't looked at it recently.
Yes and no. You might be right that these parts represent a relatively
small portion of the actual source code. But I also think that the
reason for EOF to get where it is now after 11 years (DBKit, EOF1,
EOF2, ...) is the fact that the folks had to invent all the ideas. See
what happens on the Java front... very similar development - only they
started 6 years later and decided not to learn from NeXT ;-)
I know the folks who wrote the GNU implementation (compatible to EOF1),
and I know also what effort was involved... it was not 11 years of
entire team! BTW, we seriously considered enhancing the current GNU
version, but this will be as difficult as staring from blank sheet. This
does not mean that we are not going to use some bits of it like SQL
generation, transaction sorting etc.
If you didn't want to hear people arguing against the decision you
were considering making, then it isn't clear why you asked the
question -- your mind is already made up. If, on the other hand, your
mind is still open to being changed, then please don't accuse me of
being "unconstructive" just because I'm trying to change it.
If my mind was made, I would not start this discussion. And I hate even
to think about the idea to write something that is already written, and
it is not used because of politics. I start this discussion in a hope
that someone will tell me either that he or she knows of a EOF
replacement, or point me to a local solution that will allow us to use
our code with embedded version of FrontBase (at this point I really do
not care about multiple adaptors, connection to multiple databases etc.)
What I care is to be able to get my EOs into an EditingContext without
cutting SQL and to have at least the basic EOInterface functionality.
But even if this is too much to ask, well, then we will bite the
bullet... and start cutting code.
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.