[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
OGo/GNUstep cooperation Re: Re[2]: Frameworks integration
From: |
Helge Hess |
Subject: |
OGo/GNUstep cooperation Re: Re[2]: Frameworks integration |
Date: |
Sun, 29 Feb 2004 15:16:47 +0100 |
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
- Re: Frameworks integration, (continued)
Re: Frameworks integration, Brent Fulgham, 2004/02/27
Re: Frameworks integration, S.J.Chun, 2004/02/28