[kepler-dev] Kepler distributions

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
each package.

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.

_Christopher
--------

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