[kepler-dev] Kepler distributions

Tue May 24 10:16:22 PDT 2005

Matt,

Thanks, this really helps.  I'm still digesting the KSW and Kepler  
Object Manager documents.  These technologies look like a great  
foundation for satisfying the kinds of user requirements I mentioned.

I am a little wary of automatic, on-the-fly installations of executable  
code (even with digital signatures), so a manual plug-in manager of  
some kind would be great as well.  Dragging actors out of the  
repositories one at a time is great for exploring what's out there, but  
for "production" use I'd prefer to download whole packages of actors  
that were developed and tested together, have a collective version  
number, can be upgraded or downgraded together, are maintained by a  
reputable organization, are guaranteed to be around for a long time,  
can be referenced collectively in a publication, etc.

Tim

On May 24, 2005, at 9:00 AM, Matt Jones wrote:

> 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
> -------------------------------------------------------------------
>