Re: State of Swarm on Mac OS X

[Ed Baskerville]

At the risk of speaking without knowledge--I still haven't used Swarm,
ever, and feel like an impostor posting this--but here are some thoughts
(mostly a summary of what's been said).


I see two goals emerging:

(1) Get Swarm running on Mac OS X. This essentially means the standard
(read: completely nonstandard) Unix porting process.

(2) Get Swarm packaged prettily on Mac OS X. This means a Project Builder
project, perhaps a framework, etc. On a less cosmetic level this means
(3)...

(3) Get Swarm to integrate with Cocoa/GNUstep. This currently would
involve crossing between incompatible messaging systems--through
straight-C glue code or some other mechanism.

(1) and (2) are porting/Mac OS X issues.

(3) points to more fundamental issues with Swarm: it is tied in a
low-level way to the runtime environment.

My opinion is that converting Swarm to GNUstep/Cocoa is a great idea, with
no ties to the native runtime. It will take work now, but will make the
project far easier to maintain and use in the future.


By moving to GNUstep/Cocoa, Swarm gains the following at the very least:

- A well supported foundation layer that will continue to evolve and
improve without the efforts of Swarm developers--the burden shifts to
GNUstep and Apple. Swarm developers' time is better spent on Swarm
specifics, not on duplicating Foundation.

- Easy integration with one of the most powerful application frameworks in
existence.

- Real portability. Anything that runs on GNUstep should run on Cocoa with
little more than recompile.

- Any runtime benefits Apple and GNUstep developers add in the future.


The three primary pitfalls that come to mind:

- Performance. If this really is an issue, any patches to the runtime must
be rolled into GNU. If there are issues with Apple's runtime, bring them
up with Apple. (Being a Cocoa tech writer for Apple, I can ask around for
[non-secret] answers to questions.) During the conversion process,
cooperation with the developers of the lower layers is key. When viewed as
a longer-term goal, performance is something that can be fixed.

- Time and effort. Free software takes free labor.

- Really maintaining portability. If Swarm is kept as a non-GUI, pure
Foundation-based framework, everybody will be happier. GUI stuff can be
built on that, but should be kept separate--a Swarm "AppKit", for example.


Also, I'm sure there are other things going on with the development of
Swarm that I'm not aware of. (Let me know if I'm way off base with any of
this.)

As for fast, good, and cheap? I think we can have all three: fast by
working with the runtime folks; good by taking the time to do it right;
and cheap...well, not cheap to those doing the work (time = money), but
still free software.

My few cents.

Ed Baskerville
University of Michigan
Undergraduate Student - BSE (Computer Science)


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.