[kepler-dev] Kepler distributions
cxh at eecs.berkeley.edu
Tue May 24 07:54:51 PDT 2005
I like the incremental loading of the bare Ptolemy II configuration.
I really see the need for the search mechanism that Kepler has.
One possible solution would be to split the search data and the actual
code, so when the user searched, the java code for the actor need not
necessarily be loaded. Probably the thing to do would be to have a
harvest step at build time that would create the search data for
It would also be nice to have a way to say at run time, query all the
actors and update the database.
Note that the bare Ptolemy II configuration can load the entire
configuration via the about: facility. To see this in action,
go to the copyright page and then follow the
"Other information about this configuration" link at the bottom.
This will bring up a page that includes links that will load
the entire configuration and also run all the demos.
The right thing would be to further extend this facility so
that it reads more info from the configuration to determine exactly
what links are present. To be more specific, if _aboutFiles was
as list of files in the configuration, then each element of the
list would be displayed in the about: page with a link.
Anyway, the above is just my $0.02. I need to learn more about
the Kepler search mechanism.
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
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
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
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
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
More information about the Kepler-dev