[kepler-dev] Kepler distributions

[Timothy McPhillips]

All,

The  ongoing "PtolemyII 5.0beta release" discussion has been quite 
interesting.  I've been thinking about the question of what actors 
should be in the base Kepler distribution, as well.

(I'd very much like to put together a custom release for my users by 
the end of 2005, so please count me among the "resources" available for 
working on whatever is needed to get a general release of Kepler 1.0 
ready to ship.)

I just started moving my phylogenetics actors and workflows from the 
Ptolemy II environment into Kepler.  I'm really enjoying playing with 
and digging into Kepler.  I was a little surprised, though, to find 
that starting up Kepler, with a workflow specified on the command line, 
took 60 seconds, whereas it takes 12 seconds to do the same using 
Ptolemy's Vergil (both started from within Eclipse on my 1GHz G4 
PowerBook).  Today I created my own minimal Kepler configuration (and a 
nearly empty actor ontology) and got the start time under 25 seconds 
with no standard Kepler or Ptolemy actors being loaded at all.  
(Clearly there is a lot going on in Kepler that is not happening in 
Ptolemy, actors aside--the 12-second start time is for a default set of 
Ptolemy actors plus my actors.)

My target user community will not necessarily need all of the actors 
that come with Ptolemy and Kepler at the moment.  Their main interest 
will be the stuff specific to their scientific domain.  I suspect they 
will prefer to download (and will be less confused by) a distribution 
of Kepler customized for phylogenetics that does just what they 
need--and starts quickly and runs fast.  Of course, they'll also 
(eventually) want to browse actors available for other domains and 
optionally install them.

Based on this speculation, here are my thoughts on packaging and 
distributing Kepler.

1.  We could provide a bare-bones, core Kepler distribution that 
doesn't do much, is small and quick to install, contains no 
science-domain specific actors (or other domain-specific code), 
contains a minimum of third-party jars, and contains no 
platform-dependent code.

2.  We would then need to provide an easy way to browse, download, and 
incrementally add "science-domain packages" to a Kepler installation.  
Each package could include the set of actors and corresponding support 
library jars for the domain.

3.  We could additionally  provide a selection of domain-specific, 
customized Kepler installers equivalent to the minimal core 
distribution plus one or two science-domain packages.

4.  To keep things snappy after the user has installed a number of 
different packages, it would be nice if the user could specify custom 
run-time configurations that load only those domains (and corresponding 
actors and support jars) specified in the selected configuration.

5.  It also would be nice if we could facilitate installation and 
configuration of external software packages needed by particular 
science domains (e.g., the phylogenetics software wrapped by my 
actors).  We could provide downloads and installers for these packages 
when practical (and legal); provide a tool for managing references from 
Kepler to external software packages (instead of, say, using fixed 
paths to these programs in source code); and allow use of existing 
installations of these external packages (when the versions are 
compatible).

6.  We could also provide packages for particular technology domains.  
For example, if there are no Globus resources for phylogenetics yet 
then my users won't need Globus actors in their first installer.  But 
they might want to install Grid support later.

Anyway, these are my thoughts at the moment.  I'd love to hear what the 
current plans and works-in-progress are in these regards.

And again, I'd really like to help any way I can.  I'll even write 
documentation!

Cheers,

Tim