[Biococoa-dev] GNUStep Compatibility

[Alexander Griekspoor]

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

***************************************************************