[kepler-dev] Kepler distributions

[Matt Jones]

Timothy,

My last thread regarding KSW I think addresses all of the issues you
raise below from a technical perspectice, but not necessarily from a UI
perspective.  A plugin manager UI would probably be useful to complement
the automatic download capabilities.

As an aside, our plans for searching remote repositories for KSW files
includes exploiting the metadata in KSW files.  When implemented, the
user will be able to search for actors and workflows in the left pane,
and they will find actors that are present on their local system and
actors that are present in network repositories for download.  Both of
these will show up in the tree on the left, and dragging a
network-accessible actor from the tree on the canvas will cause Kepler
to download and load the necessary KSW files to support the actor.

Matt

Timothy McPhillips wrote:
> 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
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------