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

On Aug 23, 2005, at 5:01 PM, Helge Hess wrote:

> Hi Pierce,
>
> maybe this is better placed on some Cocoa/WO/SOPE mailing list.  
> Anyway.
>
> On 23. Aug 2005, at 23:20 Uhr, Pierce T. Wetter III wrote:
>
>>     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.
>>
>
> Could you elaborate on the NSArray vs NSSet issue?

   EOF used NSArrays in EOEditingContext and in many of the internal  
structures, so it ended being order(N) or order(N^2) for many  
operations. Its ok for fetching 20 objects, but if you fetch 10000...

   You can see this in AJR in EOEditingContext when it has to see if  
it already has an object matching a given globalID, it has to scan an  
array.

   NSSets would scale better.

>
>
>> It has 3! database adaptors for it, and an EOModeler implementation.
>>
>
> I don't consider this a serious limitation, database adaptors are  
> rather easy to write, we have such for various databases (SQLite,  
> MySQL, PostgreSQL, Sybase, Oracle). The last two I wrote (SQLite  
> and MySQL) took less than a day each.
>
> That adaptors-are-hard is just a myth invented by Apple (just like  
> the myth that maintaining .jobs files is actual work).

   I dunno if its a myth as much as it was never well documented and  
only the FlatFile adaptor was open source before.
>
> EOModeler just become less important with Xcode 2.1, I'm not really  
> interested in clones (unless they are cross platform, eg based on  
> XUL or Eclipse).

  I agree.
>
>
>>     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.
>>
>
> So far I have the impression that AJR is the best available option.  
> It might not have everything which is in EOF, but what I've seen  
> looks quite good and well done (in other words: better than GDL2).
>
> Sooner or later I plan to import AJR into SOPE, as sope-ajr  
> alongside sope-gdl1. But this is probably quite a bit in the  
> future, I consider other features (like D2W and WebScript) more  
> important.
>
> Very rough SOPE Planning:
> 4.4 - stable release for OGo 1.0 (in progress)
> 4.6 - D2W features, CoreData, proper OSX support (eg packages)  
> (this year)
> 4.8 - plenty of AJAX/Prototype elements (?)
> 5.0 - WebScript (?)
> 5.2 - EOF clone (?)

  Personally, rather then WebScript, I would do "python for SOPE" or  
something similar. That is, there's nothing particularly magic about  
WebScript, it wasn't really that great a scripting language.

   I never got much into D2W personally.




>
>
>
>>     GDL2: www.gnustep.org
>>
>>     This use its own build system, so its a significant commitment  
>> just to build the damn thing.
>>
>
> Gstep-make is the best thing which ever happened, far better than  
> this Xcode crap which you need to change with every minor software  
> update.

  If you say so. I don't think the Xcode build system is that great,  
no, but its an OK IDE  otherwise. All IDEs have upgrade issues...


>
> To build SOPE (trunk) with gstep-make on OSX you just do:
>   ./configure --frameworks=/Library/Frameworks
>   make install
> and you find the frameworks in the given directory. Say "make  
> macosx-pkg" and you'll get Installer packages.
>
> The issue you have with GDL2 is that nobody really cares about it,  
> of course this also reflects in its build system, its definitely  
> not related to gstep-make.

   Yeah, its kind of stagnated for a year.

>
>
>> It uses NSHashTable instead of NSArrays in the EOEditingContext so  
>> it has the possibility of being _faster_ then EOF which is  
>> interesting.
>>
>
> I'm not aware that in-memory operations where an actual problem  
> with EOF?

   Yeah, arrayExcludingObjectsFromArray was the bane of my existence  
for awhile, until I patched it to use NSSets instead. It was faster  
to build two sets and do the operation then it was to do an NxM  
operation...

>
>
>>     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).
>>
>
> Nat! is doing this as part of a project, so AFAIK all the work is  
> already fully paid for. If you want to see it OpenSource, I think  
> you will need to successfully convince him how this will make him  
> additional money (I failed), otherwise he has no point to release  
> it either.

   It will lead to consulting projects, which is part of codeon's  
business. In my experience when I was a consultant, doing stuff like  
that was the best resume imaginable.


>>     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.
>>
>
> There is work in progress to integrate CD with SOPE and so far I'm  
> quite pleased with the results. I think it might be pretty good for  
> lightweight web applications and allows to take advantage of all  
> the advanced WO features, like D2W.

   Huh, that will be really cool for SOPEX apps.

>
>
>
>>     Summary:
>>
> ...
>
>> Probably easier for the AJR guys to steal rabidly from GDL2 into  
>> AJR then fuss with all the GnuStep stuff in GDL2.
>>
>
> - AFAIK AJR development is more or less stalled because Alex is  
> busy with
>   other stuff. Yet it IMHO has source which I consider maintainable  
> and might
>   consider to look into in case of bugs.
> - GDL has no "visible" progress and personally I consider it  
> unmaintainable,
>   I wouldn't look into it.
> - MulleEOF is likely to be closed source and therefore not  
> interesting to me.
> - CoreData might be quite OK for my requirements. Having DB  
> adaptors would be
>   nice though. Biggest drawback: only OSX.

    Biggest drawback: No network databases, no DB adaptors for  
anything but XML, SQLlite and NSArchives, and no concept of multiple  
reader/writers to the same database.

>
> Summary: AJR for DB access, CoreData for small new apps.

   Fair enough.
>
>
>>     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.
>>
>
> Well, software development doesn't work this way. NIH.

   I have a dream!
>
>
>>     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.
>>
>
> SOPE also did this in steps, the first one being the WO  
> reimplementation _and then_ we just integrated new ideas when  
> _other_! people invented them (Zope).
> In the context of EOF this means:
> a) we have no complete EOF yet
> b) there are no really new ideas to improve the situation
>
> Having said that I have the impression Nat! will improve EOF  
> greatly while still being compatible.
>
>
>
>>    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.
>>
>
> I don't think that EOF is sooo important here. Its interesting only  
> for a very small niché of developers (those dealing with highly  
> complex DB structures) and then those are usually not considering  
> an Apple/ObjC solution anyway but go straight for Java/.NET (quite  
> understandable).

   Ugh, that Java stuff is still awful.
>
> We can make SOPE a success without a full EOF implementation. CD  
> will be great, AJR will be better.

   Oh, sure. SOPE is awesome. I just can't easily use it yet. :-)

>
>
>
>>    And someday perhaps:
>>        3. Interacts with databases better:
>>
> ... can't say anything on that ...
>
>
>>        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...)
>>
>
> Java/Swing is dead. Personally I would like to see several things  
> here:
> a) D2AppKit
> b) D2XUL
> c) D2AJAX
> Maybe
> d) D2Avalon
> might become interesting too. In 5 years or so ;-)

   I'm thinking of a Cocoa-client actually. Java client had this  
great concept of

    app -> local editing context:network: server -> real editing context

   So you can write a smart client that thinks it can read/write  
directly to the database, meanwhile your server just has to enforce  
security, etc.

>
>
>> 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.
>>
>
> Apple WO isn't interesting for Internet development for a loooong  
> time mostly because it lacks proper URLs. It can be still cool with  
> Intranet development, but since it doesn't fit well with AJAX, this  
> is likely to die as well unless Apple invests significant resources  
> (which I doubt).

    Check out www.marketocracy.com, I fixed that pretty easily...

    I'll have to go look into AJAX now...

  Pierce