[kepler-dev] Kepler Alpha2 Installer Problems

[Dan Higgins]

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