OGo/GNUstep cooperation Re: Re[2]: Frameworks integration

[Helge Hess]

On 29.02.2004, at 12:36, Manuel Guesdon wrote:
> > | First:  EOF is a completely separate issue, of course you could also
> > | use GDL2 with SOPE and this isn't part of gnustep-web.
>
> EOF is part of WO. And most WO users won't use a wo 'clone' without it.

Not sure what you want to tell us with that.

EOF is part of the Apple WebObjects product, yes, but EOF isn't part of 
the WebObjects *framework* and isn't part of gnustep-web either, but a 
separate project which can be used by either gnustep-web, AppKit 
applications or of course by SOPE.
There is nothing in the EOF framework which depends on WO and very 
little in the WO framework which depends on EOF (and nothing which 
depends on EOF/RDBMS, just EOControl).
So, the statement stands: "EOF is a completely separate issue".

Unfortunately most WO users won't use an Objective-C WO clone anyway, 
because all but some already moved to WO/Java. But we'll see what we 
can do about that - the SOPE:X work by ZNeK is certainly a huge step 
forward ;-)

> > | Second: I think NGObjWeb is more compatible with WebObjects than
> > | gnustep-web (eg concerning template parsing, though we have stripped
> > | out some stuff for OGo [but could put back things like "WEBOBJECT"
> > | instead of "#" or .woo files in case someone actually cares <I guess
> > | not>]).
>
> Concerning template parsing in GNUstepWeb, it's open, just write 
> another template parser and plugin it. There's already ANTLR one and 
> html/xml one and you can choose even component by component which one 
> to use.

See Manuel, I *really* don't want to lower your work on gnustep-web. 
Yet a comment like "just write another template parser" is 
inappropriate for the discussion, since WO compatible parsers (and many 
more things) are already *finished and mature* in NGObjWeb and they 
were finished and mature for years when you started working at 
gnustep-web! Thats the whole point.


[OGo/GNUstep cooperation]

So in my opinion the question is to find out how GNUstep and OGo can 
work together instead of working on the same things twice - naturally a 
lot of things should be possible to share in case people want to (well, 
and at OGo we are very open to this ;-). There are various areas where 
this just works or works with minor tweaks and others, like 
gnustep-web, which are much more problematic.

Some examples:

For example by the help of Nicola and some others we are getting 
forward in using gnustep-base instead of libFoundation and gnustep-make 
instead of OGo-variant of gnustep-make.
Gain for OGo: The GNUstep solution is clearly superior in this case, 
more developers, more functionality, better focus on the actual project 
"Foundation library".
Gain for GNUstep: tens of thousands of people actually using the 
framework (even if they are not aware ;-) - basically OGo would be a 
huge reference for the applicability of gstep-base.

As Nicolas suggested, skyrix-xml might be the primary XML(/STX,iCal,..) 
parsing framework for GNUstep in case people can agree on that. Also 
helps both projects.
Gain for OGo: more "maintenance" developers and possible enhancements
Gain for GNUstep: a finished and working tag parsing framework

Using GDL2 in OGo might be a possibility, but I'm not sure on that 
because of the patent issues involved with that (OGo EOControl has 
stripped out the parts in question, like EOEditingContext). At least it 
could be an option.
Gain for OGo: well, EOF 2 for SOPE users
Gain for GNUstep: like for gnustep-base/make: loads of users

Then we have StepTalk - could be somehow merged with SOPE 
NGScripting/NGJavaScript, but is probably some work. Maybe Stefan would 
like to help with that.
Gain for OGo: more scripting languages for OGo/SOPE
Gain for GNUstep: SpiderMonkey/JavaScript support, users

Pantomime/NGMime. Also somewhat difficult. I have the impression that 
Pantomime is as mature (though probably not tested to the same extend) 
like NGMime (part of skyrix-core) and might have a better API. The 
gains of using a single framework for both projects is obvious (since 
mail is especially a testing intense issue due to all the crap 
submitted by the various mail clients).
Not sure how we can deal with that, since (unlike for WO), there is no 
common ObjC mail-API. Maybe Ludovic has some suggestions.

And finally gnustep-web/SOPE: this obviously clashes. Gnustep-web from 
a functional point of view is mostly a subset of SOPE. And it isn't 
nearly as widely tested and optimized as SOPE. It obviously makes no 
sense at all to use it as the application server framework in OGo.
The pro argument for GNUstep on gstep-web is the FSF copyright 
assignment, though this is irrelevant for users given that SOPE is LGPL 
as well.
So the result is, that we are currently communicating two differents 
frameworks to developers and users which are supposed to do the same 
thing, which in turn duplicates work for us and splits the user 
community (if it actually does, more likely most/all WO developers 
would use SOPE:X).
I think we should try to find a way out of this if possible. Its an 
unfortunate side effect of OGo being developed in a proprietary way 
before that Manuel (and others?) have invested so much work into 
gstep-web. Yet, this shouldn't result in closing the eyes on the actual 
development state.

best regards,
  Helge
--
http://docs.opengroupware.org/Members/helge
OpenGroupware.org