Fwd: GDL2 on MacOS X

Stéphane Corthésy <[email protected]>
Newsgroups gmane.comp.web.webobjects.eof,gmane.comp.macosx.devel
Message-ID <[email protected]>
(Discussion will take place on [email protected] mailing list - end 
of crossposting)

Begin forwarded message:

> From: Adam Fedor <[email protected]>
> Date: Wed Nov 20, 2002  04:21:46 Europe/Zurich
> To: Stéphane Corthésy <[email protected]>
> Cc: [email protected],  [email protected],  [email protected]
> Subject: Re: GDL2 on MacOS X
>
> Stéphane Corthésy wrote:
>> I have some questions now:
>> - What is the current state of gdl2?? How compatible is it with EOF 
>> 2? WebObjects 4.5's EOF implementation?
>> - Do gdl2 developers plan to support MacOS X? If they reply "no", no 
>> need to read remaining questions ;-)
>
> They (we?) should. Although I don't think any of the main developers 
> use MacOSX so we would rely on patches and bug reports from others.
>
> I don't think your patch will work though, since you  need the garbage 
> collecting classes for gdl2. We're working on a compatibility library 
> that you could compile on MacOSX to get this to work.
>
>> - Does it even compile on a GNUStep system?? I had to correct some 
>> code, independant of platform.
>
> Well, understand that it's not even a released version yet, it's just 
> in CVS.
>
>> - gdl2 depends on GNUStep-specific classes, like GCArray, etc. Can 
>> this dependency be removed? There are also references to methods not 
>> implemented in MacOS X, like subclassResponsibility:, but in these 
>> cases we could implement categories on MacOS X for GNUStep 
>> compatibility.
>
> see above.
>
>> - gdl2 is not consistent regarding retain/release and garbage 
>> collecting; sometimes macros are used for retain/release, sometimes 
>> method calls are used. How should it be done?
>
> macros should be used, since it's possible to compile GNUstep with 
> automatic garbage collection, so that retain/releases aren't even 
> needed.
>
>> Finally, I suppose there are a lot of Cocoa developers willing to use 
>> EOF... erh gdl2 ;-)
>> I suppose GNUStep people will find help among them. There are also a 
>> lot of former OpenStep/WO4 developers that could help, now that there 
>> is a concrete opensource EOF for Cocoa. So please, subscribe to that 
>> list, checkout gdl2 and give GNUStep developers needed help. I'll try 
>> to.
>
> Yes. Thanks!
>
>
> -- 
> Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, 
> because
> http://www.doc.com                    | if I didn't, I'd eat it, and 
> you
>                                       | know how I hate the stuff.
>
>

Begin forwarded message:

> From: Adam Fedor <[email protected]>
> Date: Wed Nov 20, 2002  04:36:59 Europe/Zurich
> To: "Timothy J. Wood" <[email protected]>
> Cc: Stéphane Corthésy <[email protected]>,  [email protected],  
> [email protected],  [email protected]
> Subject: Re: GDL2 on MacOS X
>
> Timothy J. Wood wrote:
>>   How are you dealing with the fact that EOModel and EOEditingContext 
>> are patented (6,085,197; 5,956,728; 5,873,093)?
>
> I don't have a great answer for this. Heck, even things like the next 
> key view concept are patented. GNUstep has always been walking on thin 
> ice wrt Apple, which has always taken a dim view of any sort of 
> infringement. Perhaps it's because we're free software. Or perhaps 
> it's because we're really about the interface, not the implementation, 
> which can always be changed. Although in this case, it's very very 
> hard to make gdl2 work without infringing the patent: gdl2 was really 
> written over a year (maybe two?) ago - we just spent the last year 
> thinking about legal issues...
>
> I imagine any commercial users will have the hardest time deciding 
> whether to use this or not. After all, it's much better to sue people 
> who actually have money. Although, since gdl2 is a drop in replacement 
> and you wouldn't be distributing it yourself...ah, but then those 
> lawyers are wiley creatures...
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.