[kepler-dev] Demo setup...

[Matt Jones]

Christopher,

We're having similar issues with code growth in Kepler, which has been
part of our motivation for developing the KSW archive format for
transporting MOML models and executables.  The KSW will allow us to wrap
up functional groups of code (metadata, executables, data, native libs,
jars, etc) such as Daniel's and load them into the Kepler runtime -- all
dependencies for a module would be resolved at runtime.  This will allow
us to ship Kepler as a core framework with a series of KSW files that
represent additional functionality such as the JINI distributed SDF work
that Daniel did.  Some of the core functional KSWs would ship with
Kepler, while others would probably become optional downloads that would
be retrieved when a user is interested in that function or when a model
requires it.

At the meeting Friday we'll be reviewing progress on implementing the
KSW and supporting infrastructure, so it will be good to get your
evaluation of it there.  We have some basic parts of it in place but
need to handle the more advanced parts such as code signing.  Looking
forward to your input on that.

Matt

Christopher Brooks wrote:
> Hi Daniel,
> 
> Sorry for the delay, I had to prep for a conference next week.
> 
> 
>>Hi Christopher,
>>
>>I have prepared the infrastructure for the demo i was talking about. For 
>>that i have setup some scripts that allow the user to launch:
>>
>>- startjinilocal: launches a local http server (daemon) and the reggie 
>>service (registration and lookup service).
>>
>>- startserver: launches a starts a DistributedServerRMIGeneric server.
>>
>>- starttservers: launches a given number of DistributedServerRMIGeneric 
>>servers depending on the parameter. (e.g. startservers 5 launches 5 
>>servers).
>>
>>This can be used so that from the demo we automatically launch the 
>>servers needed or at least provide the user with an easy way to run the 
>>Jini requiered services...
> 
> 
> Excellent!
> 
> 
>>I have made both Bourne Shell and Batch (windows) versions of the scripts...
>>
>>I have set it all up so that all the jini jars are under, 
>>ptolemy.distributed.jini.jar. I have also created 
>>ptolemy.distributed.jini.config for config files required for the previous.
>>
>>Now....
>>
>>In order to be able to launch the services, there are some extra jars 
>>that are required, being:
>>
>>jsk-platform.jar, jsk-policy.jar: for security issues...
>>reggie-dl.jar, reggie.jar: registration and lookup service...
>>start.jar, tools.jar: utility to start the services... (including httpd)...
>>
>>They amount up to 1.22 Mb and they are required to have the 
>>infrastructure running.
>>
>>I need to know whether you want me to include those and whether you want 
>>to keep the jini jars where they are or move them to 
>>ptolemy.distributed.jini.jar.
> 
> 
> I'm of two minds on this.
> 1. This would mean that we are now have over 2Mb of Jini jar files,
> which really adds to the code bloat.
> 2. If we don't include the jar files, then no one will ever use this
> code.
> 
> Ok, let's go with #2
> 
> Let's go ahead and check in all the jini jar files in
> ptolemy.distributed.jini.jar.  If the ptolemy.distributed code is
> unused, I'll eventually (in a few years) remove the jars.
> 
> I'll fix configure and move the jini jars from $PTII/lib
> 
> 
>>I also have a question about the Bourne Shell scripts you might be
>>able to help me with... for the bat files i am able to launch every
>>server, httpd and reggie in separate windows with the command
>>start. I think this is pretty neat and very illustrative for the
>>user since you can follow every single server's opeation in separate
>>windows.  I have not figured out yet how to do it in the Bourne
>>Shell scripts. Do you know how?
> 
> 
> Offhand, I'm not sure how to do this portably
> You could use xterm if X11 is set up.
> 
> Or, you could create models that read command lines and invoke them.
> The Kepler CommandLine actor might help here.  There is a person
> working on merging the Ptolemy Exec actor and the Kepler CommandLine
> actor.
> 
> It would be cool if we could have a way to invoke commands and display
> the results in both a graphical and non-graphical context.
> 
> If we can run a test on a headless machine that uses this code,
> then it is more likely to survive the tests of time.
> 
> _Christopher
> 
> 
>>Looking forward to your reply...
>>Daniel

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