[Biococoa-dev] GNUStep Compatibility
peter.schols at bio.kuleuven.ac.be
Wed Sep 8 17:17:38 EDT 2004
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.
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
> 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
> 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?
> 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
>> like this. Helpfully, it was part of an FAQ that pointed out a
>> problem that's going to be significant going forward - using Xcode for
>> development will automatically include Cocoa/Cocoa.h, and THAT ALONE
>> incompatible with GNUstep. To keep things GNUstep compatible, we're
>> to have to go back and edit pretty much all of the source code we've
>> 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
>> some specific thoughts on cross-platform optimizations. If nobody
>> volunteers, I guess I'll wind up doing it, since I'm the one who's
>> 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
>> figure out the differences, and place the previous ObjC only method
>> within the appropriate compiler directives.
>> My optimistic thought is that this is going to be very painful right
>> but if we figure out a system soon, maintaining compatibility going
>> 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
>> 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.
>>> 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
>>> only on our platform (probably using compiler tricks to switch
>>> 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
>>> 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
>>>> 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
>>>> you like them too.... it will take the GNUstep team quite some time
>>>> 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
> ** 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
More information about the Biococoa-dev