[Biococoa-dev] GNUStep Compatibility

[Peter Schols]

Alex,

I think you are totally right and your comments are very convincing and 
they make a lot of sense. As I explained, the only reason that GNUstep 
is even mentioned on the BC homepage is to get the application note 
accepted in Bioinformatics (which BTW did not help). I never tried to 
compile it on GNUstep.
I totally agree that we should focus on making BC a great Cocoa and Mac 
OS X framework and that the rest will follow automatically.

So I'd agree to dump GNUstep compatibility for the time being.

peter



On 08 Sep 2004, at 19:35, Alexander Griekspoor wrote:

> Ok guys listen up, why don't we go for a strategy change and dump the 
> GNUStep compatibility.
>
> So our goals was to make a great Cocoa framework that would:
> - be powerful and still easy to work with
> - leverage all the advantages not only Cocoa but also are beloved 
> platform brings
> - with compact and clean open-source code
>
> And we set our minimum compatibility to MacOSX 10.2.8
>
> Now the question is whether it should be GNUStep compatibility, which 
> would have the huge advantage that it:
> - would bring our framework to the mass.
> - would skyrocket our credibility both in an academic and commercial 
> way
>
> Well, guess what, the other side has a number of great frameworks 
> already (biojava i.e.) and who makes gnusteps apps for windows 
> nowadays? I don't even know of one! So the number of developers that 
> it would attract or would use our framework would be virtually nil (at 
> least that's my prediction). Thus, does it bring our framework to the 
> mass, yes, but only as a marketing fairytail.
>
> Then the credibility issue is that a credible thought?  I do believe 
> that it would be helpful to get publications/attention etc., but I 
> just shot it down a few lines ago, so a reviewer can if he wants.
>
> Even worse, we haven't talked about the disadvantages yet. Does the 
> following weight up against the benefits, starting with the goals we 
> originally set:
> - it would place definitely limit the number of options we have, 
> automatically making our framework less powerful, but also less easy 
> to work with.
> - we couldn't leverage many great features Cocoa offers, let alone the 
> fact that all new stuff would never be an option
> - the code will turn in a mess with all the if-defs around and double 
> implementations
>
> Furthermore, would it mean we can't use XCode and have to go back to 
> Project Builder, no way! And finally, we're with a small group of 
> people, the efforts and time it takes to check all this, read the 
> mailinglists, find out workarounds, optimize two implementations, can 
> be way better spend on other things!
>
> So why don't we just dump the GNUStep thing, I have the feeling we all 
> think this way. I agree we're all reluctant because of the PR thing in 
> the future, but first of all we're a long way from that and second I 
> have thought of taking a different strategy.
>
> Why don't we try to build this killer Cocoa framework that would be a 
> real Cocoa equivalent of the BioJava framework. It doesn't have to be 
> as big at the start, but it has to offer the same core functions and 
> be of good quality. Well that was our goal from the onset right?
> Next, when we are at that stage, we contact the people of the Open 
> Bioinformatics Foundation (OBF, www.open-bio.org), the umbrella 
> organization of BioPerl, -Java, -Python, etc. and apply to become a 
> formal project and join their foundation. Apple is even a sponsor of 
> them, and I can contact some people at Apple that I met at WWDC to 
> actually help us with that if necessary. Once under that umbrella, I'm 
> convinced that gives just as much credibility and PR as being GNUStep 
> compliant. I think even more in fact. Journals for instance will 
> definitely recognize you of being of importance with such a foundation 
> behind you, even if your project is Mac only, the fact that your a 
> sister project of BioJava and BioPerl would make it less of a problem. 
> Well, I won't put all my money on it, but I'm willing to bet it's a 
> better strategy in many respects....
>
> What do you guys think?
> Alexs
>
>
>
> Op 8-sep-04 om 18:20 heeft John Timmer het volgende geschreven:
>
>> I looked over the GNUstep site, and they do have a compiler directive
>> (#ifndef GNUSTEP) that they specifically recommend for avoiding 
>> problems
>> like this.  Helpfully, it was part of an FAQ that pointed out a 
>> fundamental
>> problem that's going to be significant going forward - using Xcode for
>> development will automatically include Cocoa/Cocoa.h, and THAT ALONE 
>> is
>> incompatible with GNUstep.  To keep things GNUstep compatible, we're 
>> going
>> to have to go back and edit pretty much all of the source code we've 
>> made
>> recently in order to ifndef every set of import statements, and we 
>> have to
>> be very careful going forward.
>>
>> Given all this, I think it might be valuable to have someone sign up 
>> to the
>> GNUstep-dev mailing list and hash out some of the issues.  They may 
>> have
>> some specific thoughts on cross-platform optimizations.  If nobody 
>> else
>> volunteers, I guess I'll wind up doing it, since I'm the one who's 
>> caused
>> the problem anyway.
>>
>> Incidentally, I've only optimized existing methods so far, so it 
>> should be
>> relatively simple (if extremely tedious) to go back in the CVS 
>> history,
>> figure out the differences, and place the previous ObjC only method 
>> back
>> within the appropriate compiler directives.
>>
>> My optimistic thought is that this is going to be very painful right 
>> now,
>> but if we figure out a system soon, maintaining compatibility going 
>> forward
>> might not be that bad.  My fear is that Apple's Xcode updates will 
>> make it
>> harder.  To me, the decision seems to be about whether it's worth 
>> losing
>> some PR and academic credibility in order to provide something to a
>> community that's unlikely to care. I'm not entirely sure where I 
>> stand on
>> that issue.
>>
>> John
>>
>>
>>> Now we're starting to talk about the real thing, we need a PR person
>>> ;-) Again, for me the only reason to stay GNUStep compatible is a
>>> marketing technical one. The question would be to John and Koen, how
>>> much work would it be to either optimize without CF usage, or 
>>> optimize
>>> only on our platform (probably using compiler tricks to switch 
>>> between
>>> with or without optimization)?
>>> I do have noticed indeed that without the "on-multiple-platform"
>>> argument it's often hard to sell a Cocoa framework to the mass or get
>>> articles/sponsorships...
>>> Alex
>>>
>>> Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven:
>>>
>>>> Hi Alex, Jim and others,
>>>>
>>>> Last year, we have tried to submit an application note about BC to
>>>> Bioinformatics. The application note did not get accepted, mainly
>>>> because the only reviewer (!) was a Mac-hater. Bioinformatics only
>>>> accepts application notes about open-source software that runs on as
>>>> much platforms as possible (mostly Java or C apps). That's the 
>>>> reason
>>>> why we emphasized the cross-platform possibilities with our BC 
>>>> code. I
>>>> think we should still try to submit an application note to BI (or
>>>> another journal) within a few months, when we have a stable BC
>>>> release. If the list agrees with that, compatibility with GNUstep
>>>> would be necessary. On the other hand, I love many of the recent
>>>> additions: bindings in Panther, core data in Tiger and I guess many 
>>>> of
>>>> you like them too.... it will take the GNUstep team quite some time 
>>>> to
>>>> integrate them, if they appear at all...
>>>>
>>>> Whether we should keep our framework below its own speed and
>>>> possibilities just for the sake of GNUstep compatibility is a hard
>>>> question. I'd be interested in your opinions.
>>>>
>>
>> _______________________________________________
>> This mind intentionally left blank
>>
>>
>> _______________________________________________
>> Biococoa-dev mailing list
>> Biococoa-dev at bioinformatics.org
>> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>>
>>
> **************************************************************
>                         ** Alexander Griekspoor **
> **************************************************************
>                  The Netherlands Cancer Institute
>                  Department of Tumorbiology (H4)
>             Plesmanlaan 121, 1066 CX, Amsterdam
>                        Tel:  + 31 20 - 512 2023
>                        Fax:  + 31 20 - 512 2029
>                       AIM: mekentosj at mac.com
>                       E-mail: a.griekspoor at nki.nl
>                    Web: http://www.mekentosj.com
>
> MacOS X: The power of UNIX with the simplicity of the Mac
>
> ***************************************************************
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev