[kepler-dev] Export to KAR

[Chad Berkley]

Hi Norbert,

See my responses below.

Norbert Podhorszki wrote:
> Hello Chad,
> 
> Thank you for bringing export/import back to Kepler. I have already 
> created two actors and then workflows using them. And have some comments 
> about it.
> 
> 1. There is a difference between Java actors and workflow actors. When a 
> workflow actor is instantiated, it is practically copied into the 
> workflow. Thus, at save, the workflow code contains the actor's code.
> That is, if I re-create the actor, this has no effect on the saved 
> workflow. Which is of course not this way for Java class based actors.
> Is this intentional, or it just works this way?

This is a design issue within ptolemy which we have been trying to 
change somewhat.  In PTII, not all actors are required to have a 
metadata descriptions (MoML).  In Kepler, we are trying to force all 
workflow components to have metadata descriptions but since there are no 
fewer than 4 different "kinds" of components, it's turned out to be more 
difficult that we thought.

> 
> In contrast, there are several hand-made workflow actors (see the
> src/org/resurgence/moml directory for workflows and then src/actors for
> the actor definitions). The test workflows show that only a reference to 
> the actor is saved within the test workflow (see 
> workflows/test/resurgence/moml).
> 
> I gave up trying to follow the hand-made way when my actors threw lots of 
> ptolemy type check errors before starting the workflow... So the export 
> menu brought me relief.
> 
> 
> 2. I tried to trick the exprot by creating a workflow class from a 
> workflow and then export it. Surprisingly, the exported xml is nearly 
> empty. It contains only the enclosing stuff but not a single entity.

Classes are tricky.  For a while, I had it so that you were forced to 
create a class from a composite before you could create a kar file. 
This made the kar files more simple because you could then instantiate 
them however you wanted and i didn't have to worry about all the 
internals of the instantiated object.  people didn't like this approach, 
so I changed it so that you could create a kar file from an instantiated 
composite.  This was working when I stopped working on Kepler in April, 
but I haven't tried it since.  After I changed it, I don't think I 
tested to see if karring up a class would still work.  The moml you got 
seems weird.  I'll have to mess around with that to see what I can 
figure out.


> 
> 
> 3. The final actors of mine are created with the following procedure:
> - export workflow to kar
> - unzip kar
> - edit the xml file, defining SemanticTypes so that the actor appears in
>    the actor tree where I want.
> - jar into a new kar
> - put the new kar into kepler/kar/actors    (instead of import)
> No question here, just documented my practice. If you find this ugly, or 
> know a better way, just tell me.

You can actually stream line that a little.  You don't have to edit the 
kar file to change the semantic type.  Instead, before you create the 
kar, you can "configure" the actor or workflow, then add a semanticType 
property (class org.kepler.sms.SemanticType) via the GUI.  Then when you 
export, the semantic type will already be in the actor/workflow and you 
shouldn't have to mess around with unjaring the kar file.

Now that I'm back on Kepler for a while, hopefully I'll be able to get 
more of this straightened out.  Let me know if you find any problems or 
have any suggestions.

chad