Eaten by the Tiger? Open Source WO is coming...

  Our previous hacking of WO 4.5.1 to get it to work on 10.1, then  
10.2, then 10.3 seems to be stuck at the moment on 10.4.

  Don't get me wrong, I think its great that they're moving KVC into  
the mainstream even if:

    1. They broke NSArray and NSSet.
    2. They forgot to expose the API for writing your own array  
accessors.

  But I digress.

  We'll probably be able to hack around it (again) by replacing the  
valueForKey: implementation on NSArray and NSSet, but its clearly  
getting time for us to move to SOPE, and an EOF clone (since the gdl1  
in SOPE is inadequate).

  First off, SOPE kicks ass with some of the best features of both WO  
and Zope. So it wins hands down. Plus you can get XCode projects for  
building the damn thing, and can even write Cocoa apps that work like  
WO apps behind the scenes.

  But SOPE only has gdl1, which is like pairing a rocket engine to a  
donkey cart.

  So the real issue is what to replace sope-gdl1 with.


   Here's my evaluation so far:

     AJRdatabase: http://sourceforge.net/projects/ajrdatabase

     This is an XCode project, so its the simplest to build and get  
going. However it does the same annoying thing EOF does, which is use  
NSArrays for everything in EOEditingContext instead of NSSet. So it  
will have the same unnecessary scaling problems as EOF, though that's  
probably fixable in a simple way. It has 3! database adaptors for it,  
and an EOModeler implementation.

     It's about 22871 lines total of .m files for EOAccess/EOControl.  
It's not clear exactly how far along it is to being a full EOF clone,  
some of those objects are clearly stubs.


     GDL2: www.gnustep.org

     This use its own build system, so its a significant commitment  
just to build the damn thing. It uses NSHashTable instead of NSArrays  
in the EOEditingContext so it has the possibility of being _faster_  
then EOF which is interesting.

     It clocks in at 51962 lines but its hard to say if that means  
more coverage because some of that is clearly duplicating things  
already in Foundation for Gnustep, like KVC.

     It's at about the level of EOF from WO 4.0, which means no  
shared editing contexts (which didn't work anyways in 4.5) or  
EOGenericRecord  (which did work but weren't that useful.

     Nat!:

     Nat! has blogged about writing his own EOF clone, which  
dubiously he thinks he might charge for (in other words, he found out  
its a lot of work, and he's not getting any help). Since I could  
barely tolerate Apple's implementation, it makes me nervous to not  
have source. Plus a big part of EOF is writing all the database  
adaptors, so that will be hard to get other people to do if its not  
open source. Since I haven't seen it, its hard to have much of an  
opinion, but he has a great track record.

     Sometimes I wish there was a "paid" source model, where you paid  
a license fee, but you got source access.

     Apple:

      CoreData will no doubt go through revisions, but that will take  
2 years to duplicate EOF (sigh). Now that EOModeler is built into  
XCode though, any new code could leverage off of a very nice modeler  
application, so that's a lot less stuff to duplicate. So waiting for  
Apple doesn't seem like an option. CoreData is cool and a great  
direction, but it won't quite be there for some time.

     Summary:

   None of them are quite there yet. GDL2 is the closest, but its so  
hard to get going with just an initial build that I suspect AJR or  
Mulle is more likely to happen because most WO guys became Cocoa  
guys, so working on Gnustep seems too painful. Probably easier for  
the AJR guys to steal rabidly from GDL2 into AJR then fuss with all  
the GnuStep stuff in GDL2.

     This is somewhat annoying, because given 3 different EOF clones,  
you would think that if those guys had pooled their talents, we could  
have one working EOF clone, rather then 3 different groups of people  
writing 75% of an EOF clone. Though the AJR guys are stealing from  
SOPE-gdl1 so maybe AJR will leap past gdl2.

     None of these guys seem to have thought about how to take EOF to  
the next level the way SOPE has taken WO and made it WO++ yet, but  
that's probably because just cloning EOF is a major task.

    Once that's done though, we might have an ObjC WO/EOF under Cocoa  
that:

        1. Is Open Source.
        2. Scales better (sometimes, yes you do get 10,000 objects  
back from the database)

    A way the Apple solution will probably fall short of on both counts.

    And someday perhaps:

        3. Interacts with databases better: One of my pet peeves with  
EOF was that you
           could only have one transaction pending with the database  
at a time, even
           though with the way EOF interacted with the database (one  
transaction for
           the select, a later one for the insert/update), most  
databases could have
           easily handled multiple parallel reads...

        4. A client-server layer ala Java client in WO 5.0 so that  
you can easily write
        client-server applications where the business logic can live  
on the client side.
        (Just a different type of datastore...)

   Though when that happens, it doesn't seem like there will be a lot  
of reason for anyone to look at WO 6.x. But given that Apple let WO  
development stagnate for 5-6 years, that's about right; on the java  
side with Tapestry and Cayenne I don't think WO is that competitive  
anymore.


Pierce