Re: Building SOPE with GNUstep

[David Ayers]

Helge Hess wrote:

> On 05.03.2004, at 11:11, David Ayers wrote:
>
> > I use plain CVS versions of -make, -base and SOPE (I do not have 
> > Cocoa) but the problems I encountered were make file setup and libxml 
> > configuration dependent.  I'll update again and attach the output.
>
>
> I think I used gstep-make 1.8 on Cocoa, not sure (current is 1.9+ I 
> guess). Its unfortunate that gstep-make API changes do not lead to a new 
> major revision :-|

I'm pretty confident that my issues have little to do with -make API 
changes.  I believe it has to do with finding libxml2 (which is 
installed in /usr/local on my system) and the non-gnustep-make make 
rules in the top hierarchy.  But maybe I'll have time to look closer 
next week.

> > I can't comment on the WO4.5 API compatibility. (I do notice though 
> > that you consistently omit the version when talking about 
> > compatibility, which makes me wonder whether it may be 4.0 or even 3.x 
> > which you may be referring to, so maybe you can clarify.)
>
>
> I'm referring to WO 4.5. The only major changes where done between WO 
> 2.0 and WO 3.0 as you probably know. We are also adding some 5.2 
> extensions (like streaming) which may be relevant as well though never 
> available in ObjC WO.

Thanks for clarifying, I guess we a have different perception on what 
constitutes a major change.  But let's leave it at that.

> > > Consider SOPE. This will make you jump 10 steps ahead (AGAIN: not 
> > > because gstep-web developers are less capable but just because way 
> > > more time went into SOPE!). This helps *everyone*. Its "only" hard 
> > > because you need to abandon code.
> >
> >
> > This is dependent of on
> > - portability / interoperability with GNUstep (i.e. base) on the 
> > platforms supported by GNUstep
>
>
> Of course it needs to be fully ported and working on GNUstep 
> (make/base[/GDL2]). This is an obvious precondition before SOPE makes 
> sense in a GNUstep context.
> There is no question on that.
>
> > - FSF copyright assignment
>
>
> I guess we cannot solve that.

To bad... not that we necessarily need all of SOPE to be copyright 
assigned, it would already be great if you could copyright assign 
certain fragments that we may identify as being helpful for GSWeb.  OTOH 
it shouldn't be impossible to learn from your implementation and do it 
from scratch in a GSWeb context.

> > - formal coding issues.
>
>
> Not sure what you mean by that.

Would only be relevant for full copyright assignment of the project.

> > As SOPE is LGPL and you don't see yourself capable/willing of 
> > assigning the copyright to the FSF, I'm also fine with people using 
> > SOPE instead of GSWeb if they feel more comfortable with it.  
> > Personally, I prefer to complete the 'official' GNUstep package.
>
>
> Since the 'official' GNUstep also uses non-FSF assigned code thats a 
> pretty weird limitation.

Well if you mean GSANTLR (which I guess is derived from NGAntlr), then 
yes.  But removing that dependency was on my TODO list nearly from day 
one.  But that wasn't because of the copyright issue, as I didn't even 
realize it then, but because of technical issues.  It's been superseded 
by the libxml2 wrt template parsing.  It's still currently used for 
gswd(wod) parsing, but that's pretty overkill for those kind of files 
and not really worth the extra dependency.  (Another annoying 
implementation detail was the exception driven implementation that 
raised every time it finished parsing a file, which I think was there to 
mimic some java like file io handling, but I've replaced that since.)

OTOH, it's working, and ANTLR template parser was available and could be 
activated by it's users.  I also didn't realize the surprisingly small 
amount of projects that depend on GSWeb.  I thought their might be some 
out there that may still be using that parser.

So if we can replace the xml based parser with a handwritten template 
parser, I'd like to look into replacing the gswd(wod) parser also an get 
rid of the dependency on GSANTLR and ANTLR itself.

> But anyway, not going to argue on that, if you consider a FSF assignment 
> not even valid in Europe nor implemented in CVS more important than we 
> proably won't find a solution.

I have yet to see any verifiable statement that an FSF assignment is 
invalid.  Back when I first learned about the FLA I posted on the FLA 
list asking about the situation and whether it would be advisable that I 
sign corresponding papers.  I was told that my FSF copyright assignments 
where absolutely sufficient.  IANAL (but my situation may be special) so 
may I ask you to point me to an official site of authority in this 
matter that can confirm that the copyright assignment of a EU / German 
citizen is an illegal act?  OTOH, you have made it painfully clear that 
the legal issue of copyright assignment is irrelevant for you and this 
is personal/company decision that you won't contribute to the FSF.

> > > We'll do. GDL2 is probably the next thing to make people happy asking 
> > > for EOF/MacOSX support. Its great to hear that you want to work with 
> > > us on this, so finally we have anothing thing to share.
> >
> > Not quite sure what you're insinuating, but yes, you, and everyone 
> > else in the world (baring and legal export restrictions :-) ) is 
> > welcome to use this code (GSWeb and GDL2) under the corresponding 
> > license and report issues they find which we (and I'm sure this 
> > includes Manuel) will try to address.
>
>
> Well, this sounds like GDL2 is a closed project. Of course we do fixes 
> on our own and either get them incorporated (of course better) or fork 
> (less than ideal).

When I was referring to Manuel, I meant to say that he's just as willing 
to help as I am.  GDL2 is not a closed projects.  We invite anyone to 
contribute code.  We have a single requirement: FSF copyright 
assignment.  If you're not willing to contribute, then we'll just have 
to live with that.

> > But when it comes to building SOPE on GNUstep, understand that I have 
> > other priorities.
>
>
> I already wrote several times that no one is expecting that from you. A 
> cooperation is a two way thing. Of course OGo project members will work 
> to improve GNUstep related things as well as to port OGo libraries to 
> current recent things in case something is received in return.
> In the actual case of the GS port, this is already taken on by several 
> volunteers.
>
> The goal of a GNUstep/OGo is to avoid duplicate coding of the same 
> stuff. That this implies some prior work on streamlining available 
> things on both sides is somewhat obvious.
> If you priority is to reimplement already existing things, I'm fine with 
> that. After all cooperation was just a suggestion.

My priority lies with the gnustep implementations.  If others are 
willing to contribute code, that is great.  If others want to use ours, 
that's fine under the LGPL.  The point is that you seem to be unwilling 
to contribute code.  You'd prefer a non FSF project with copyright 
holders scattered around the world.  That's your prerogative.  And you 
may very well find people that support this.  That's just fine.  I've 
decided that I'm contributing to FSF assigned code.

> > IOW: if you can look at my log and tell me rather precisely what I 
> > forgot or have to tweak, I may try another build in a couple of days, 
> > but I can't investigate.
>
>
> Just wait until the port is finished, we'll drop a line when its done. 
> As mentioned the goal is to reuse the gstep-base library for the 
> official Debian packages of OGo, so there is some focus on that.

OK.  Good luck.

> Prior trying to build, you should check:
>   http://www.opengroupware.org/en/projects/gnustep/
> on the status.

Thanks for the pointer but I don't think I'm having those issues (yet :-) )

Cheers,
David