[kepler-dev] Re: [SDM-SPA] downloadable actors

[Bertram Ludaescher]

Yes, the distinctions of "generic", "domain specific" (both being
"production") and "experimental" are useful.

Also Ptolemy has a way of organizing things into "sources", "sinks",
"logic", etc.

SInce there are different ways to view and organize actors, a
"view-based" approach seems most flexible. Essentially one would have
just a heap or lump of actors and then define a tree structure on top
of that, based on user preferences.

For example there may be views such as:
-- by function (a la Ptolemy)
-- by application/scientific domain area (bio, geo, eco,...)
-- by project (SPA, SEEK, GEON, ...)
-- by "robustness" (production vs. experimental)
etc...

In order to implement that, one needs to be able to have a list of
user-definable properties of actors (e.g., an actors "signature" may
be ["experimental", "bio", "SPA", "source"].

Then these properties determine where the specific actors shows up in
each view/actor hierarchy.

If I'm not mistaken, Kepler/SEEK folks (Jing) have been looking at
some of that already (there should be some design docs/screenshots in
the Kepler CVS)

Bertram

>>>>> "V" == Vouk  <vouk at ncsu.edu> writes:
V> 
V> Xiaowen Xin wrote:
V> 
>> Hi Everyone,
>> 
>> Something that we'd like to implement as part of SPA/Kepler is an Actor
>> Repository with some actors that we don't include as part of the normal
>> distribution.  So people can go there, and download additional actors.
>> 
>> What do you all think is a good mechanism for doing this?
>> 
V> I think we need to distinguish 3 types of actors
V> - generic actors (such as webservices) which are likely to be in the 
V> distribution
V> - domain specific actors (which may be in the disttribution only if we 
V> agree that they form part of
V>     the domain library, e.g., biolib or astrolib, however we may have 
V> domain specific actors which
V>     are production, but not part of the general distribution, e.g., mattlib
V> - experimental actors (that can be anything).
V> 
V> tar ball with instructions may be sufficient for experimental and 
V> non-lib actors.
V> 
>> 
>> More specifically, we could simply distribute a tarball that includes
>> the actor source code, class file, and xml configuration file, ask the
>> user to unpackage it in a certain directory that's in her classpath. 
>> Then, ask the user to import that configuration file.  After doing this,
>> the actor will get inserted into "~/.ptolemyII/user library.xml", so the
>> next time the user runs SPA/Kepler, the system will automatically load
>> the actor.
>> 
>> However, this method seems to be quite complicated from a user
>> perspective.  It would be ideal to simply have the users download one
>> file, put it in a certain directory, and the system automatically loads
>> it at startup.
>> 
>> Dave and I have been thinking that we could potentially distribute these
>> actors as .jar files, that have the source, class file, and
>> configuration file all within.  The user could put this jar file in
>> ~/.ptolemyII/ and the system should automatically load it at startup.
>> 
V> That will work too (potential issue: since this may  not be part of the 
V> normal download associated maintenance
V>  on install of distributions, it may lead to broken installs - on user part)
V> 
>> 
>> On the downside, the implementation of this might be somewhat involved. 
>> We would need to execute something that finds all jar files in
>> ~/.ptolemyII/ and create our own classloader that has the jar files in
>> its classpath.  Then we would need to somehow add the newly found actors
>> to the treeview at the lefthand side.
>> 
>> Do you all know of any built-in mechanisms that can help do this?
>> 
V> I would keep it very simple.
V> 
V> Mladen
V> 
>> 
>> Thanks,
>> Xiaowen
>> 
>> 
>> 
V> 
V> _______________________________________________
V> kepler-dev mailing list
V> kepler-dev at ecoinformatics.org
V> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev