Swarm futures (LONG)

[glen e. p. ropella]

benedikt> So you could chalk this reason up as the 'power user
benedikt> imperative'

benedikt> Call this the 'SwarmLite imperative'.

OK.  This is probably a useful cut of the target audience of Swarm.  I
agree that Swarm is attempting to address both high-performance
computing apps and interactive intuition-building apps.  And the twain
might not necessarily have the same needs.

I would, however, rename them to something like:

 I. Computational Users  -- using Swarm for compute-intensive tasks
II. Formulaic Users -- using Swarm for model formulation

benedikt> So I guess the bottom line of this tedious message is that

benedikt> a) The best way to ensure the future of Swarm is to increase
benedikt> the potential and actual user base, by offering both high
benedikt> end and low end users a choice of development platforms and
benedikt> the ability to migrate resource intensive simulations
benedikt> between high end and low end CPUs

benedikt> b) This might be accomplished without sacrificing the
benedikt> current platform and with a reasonable amount of resources.

benedikt> There it goes. Perhaps some kind Swarmer can tell me if
benedikt> there are any glaring holes in this argument.

You're at least partially right.  A high number of potential and
actual users is a good indicator of the chances of survival.  I don't,
however, believe it's necessary or sufficient.  There are "elite"
packages that continue for a long time with very small user bases and
there are very popular packages that die for lack of resources.  But,
having said that, it really doesn't matter that a large user base
isn't necessary or sufficient.  What matters is that Swarm *wants*
users, regardless of their implications for its survival.

So, you're proposing that changing the way the GUI is handled could
make reaching both categories of user (Comp & Form) the outcome of
pursuing a single path.... namely, a move to a new GUI mechanism that
is more amenable to both groups than the present one.  Whether or not
we should go with Java or something else is a bit up in the air; but,
the important fact is that we can make steps toward this goal right
now.

Even though Swarm can be run in batch or gui (I'm tired of
capitalizing that acronym) and we have this *apparent* division
between our gui and our kernel, the two are still too incestuous.  We
can begin this process by ensuring that, as Nelson says, "the GUI is
really just a component, seperable from the rest of the system."  This
would entail repackaging the tkobjc library as a library, consistent
with the defobj library style, breaking out *all* Tk-specific stuff
from the Swarm code (including things like EZGraph, EZBin, probe
widgetry, etc), and re-packaging the control mechanism to be
compatible with controlling sims from remote processes.  Also, if we
move away from using Tk towards using something more general, then
there's probably no reason to stick with Tcl.  Other scripting
languages like Python should be considered.

In principle, it is possible to change the interface right now by
changing the shape and structure of the ObserverSwarm.  But, in order
for it to be done in a coherent and persistent way, I think Tk ought
to be ripped out of Swarm all the way down to the roots and repackaged
with the goal of switching to some other mechanism in mind.  This
means really defining robust interfaces between the gui and the
kernel.  And I think this would require alot of brainstorming on the
part of the users (mind you, I'm trying to position the SFI Hive as
users in this...  it's time for the community to assume more direction
of the project and use the SFI hive as a resource instead of an
oracle).

Just my $0.02.  

glen
p.s. I intend to repackage tkobjc sometime in the future
(I used to always use the phrase "near-future"....); but, it will
probably only happen when I have cause to do such!  And depending
on the context in which I do it, I might or might not force it 
into independence from the rest of Swarm.  Any feedback is appreciated.
Any volunteers to do it is much appreciated!