[kepler-dev] Kepler Alpha2 Installer Problems

[Christopher Brooks]

In principle, you can download .class files over the web and invoke
those classes.  However, this is a huge security issue.
It is also a best practice if the jar file is signed.

Running in the model in the sandbox might be appropriate, see
$PTII/doc/sandbox.htm

In Ptolemy Classic, we found that that the latency time of passing
tokens between actors running on remote processes was rather high.
This prevented high speed simulation.  However, for Kepler
applications transmitting data once every 'while', transmitting
tokens might be ok.

-Christopher
--------

    Hi All,
    
        Shawn's comment and some other discussions bring up some questions 
    that I thought I would post for comments/discussion.
    
        Ptolemy has an example workflow (Network Integration) where the 
    workflow is a URL rather than a local file. This allows one to post 
    workflows anywhere on a network. But as I understand MOML, this only 
    works for composite workflows; i.e. XML/MOML descriptions. Each 
    workflow, when executed, is ultimately broken down  into atomic actors, 
    written in Java and executed by calling the LOCAL class loader. In other 
    words, there is no mechanism for using remote atomic actors. Is that 
    correct?
    
        So, do we want to have a remote classloader for Kepler (load a 
    remote atomic actor to the local system), or do we want to execute 
    actors remotely and just transfer input and output tokens? (both?/neither?)
   .
    
    Dan
    
    Shawn Bowers wrote:
    
    >
    >
    > Something to keep on the back-burner that I think would be really 
    > useful, and even fit into SEEKs vision with EcoGrid and the more 
    > recent conversations concerning a file-management subsystem, would be 
    > to ship a version of Kepler that doesn't include the many 
    > actors/workflows that have been developed.
    >
    > Instead, there should be some mechanism that would allow a user to 
    > download, install, and run specific workflows/actors or packages of 
    > these that they find relevant.
    >
    > This would make it much smaller and even streamline much of the build 
    > process ... There are a ton of applications (even for Java) that have 
    > this type of "add-in" capability; and I believe in many ways Ptolemy 
    > already supports this.
    >
    > shawn
    >
    >
    >
    > Matt Jones wrote:
    >
    >> Well, I think we need to work on the size of the installer.  We 
    >> should remove the GARP test data (get it from EcoGrid instead) and 
    >> trim down the installer as much as possible.  If we can make the 
    >> installer itself much smaller then machines with less memory would be 
    >> able to better handle it.  I think we do need a traditional 
    >> installer, as the zip/batch file approach is simply too 
    >> unconventional for our target audience.
    >>
    >> Matt
    >>
    >> Dan Higgins wrote:
    >>
    >>> Hi All,
    >>>
    >>>    Mark Schildhauer recently reported problems with the Kepler 
    >>> Alpha2 installers for Windows platforms. On a machine with 256MB of 
    >>> RAM and 1-2GB of disk space, he received messages of 'not enough 
    >>> space available' when running the installers.
    >>>
    >>>    Installer tests that I (and others) have done have worked 
    >>> successfully, but they were done on Windows machines with at least 
    >>> 10GB of free disk space and 512MB of RAM. Has anyone else 
    >>> experienced difficulties with the installers (as downloaded from the 
    >>> Kepler website)?
    >>>
    >>>    An alternative which worked for Mark is to use the zip file that 
    >>> is listed as a Linux installer on the Kepler distribution page. 
    >>> Expanding this zip file creates a directory image of Kepler that 
    >>> really is platform independent. Running 'kepler.bat' will start 
    >>> Kepler on a Windows machine, while running 'kepler.sh' will launch 
    >>> it on Linux. {This assumes that Java is already installed on your 
    >>> system.)
    >>>
    >>>    Given the large size of the kepler distribution and problems with 
    >>> installers, perhaps we should consider just distributing zipped 
    >>> images and ask that user install Java separately?
    >>>
    >>> Dan
    >>>
    >>
    
    
    -- 
    *******************************************************************
    Dan Higgins                                  higgins at nceas.ucsb.edu
    http://www.nceas.ucsb.edu/    Ph: 805-892-2531
    National Center for Ecological Analysis and Synthesis (NCEAS) 
    735 State Street - Room 205
    Santa Barbara, CA 93195
    *******************************************************************
    
    _______________________________________________
    kepler-dev mailing list
    kepler-dev at ecoinformatics.org
    http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------