[kepler-dev] composite actors as kar files

[Chad Berkley]

Hi,

I've been struggling all day with how exactly I should package up a 
composite actor as a kar file.  Composites differ from atomics in that 
the "class" is a moml file.  If you "open" (or "look inside" or 
whatever) a composite and then change that composite, you will be 
prompted to save the composite actor.  When you save it, you do not only 
modify that instance of the composite, but all instances, since you are 
changing the moml class file.  (You can try this with Sinewave.)

When I create a kar file for an atomic, i only save the moml part of the 
actor (user set params, ports, etc) since the user can't change the 
atomic java source code.  This is also possible with a composite, except 
that any changes made inside the composite will be lost because the 
class will not be saved in the kar, only the moml description of the class.

One approach I have tried is to save the class and the description 
within the kar.  This would require us to alter the current kar system 
because the class would have to be loaded from the kar file before it 
could be intantiated in the system.  I'm not sure how much work this 
will be.

One thing that comes to mind is the instantiation system in ptii, where 
the composite "class" has a pink border around it and you have to 
"instantiate" that composite before using it.  I'm assuming this creates 
a new copy of the composite instead of writing changes to the original 
moml file, but i'm not sure....Can all composites be forced to act in 
this manner?  I think the "right" thing to do here is to change the 
behavior of the composites so that you are not changing the base class 
if you alter the composite.  Instead, the moml should either be 
serialized into the workflow or a subclass should be created as a 
separate file.

I'm kind of fishing for other ideas at this point because I'm really not 
sure how to handle this.  Thanks in advance for any help or suggestions.

chad