[Smartfrog-developer] Question on LAZY

[Richard A. <rac...@re...>]

Hello

I'm not quite clear on the use of LAZY in SF component descriptions.

1. My understanding was that using the LAZY keyword with a sub-component 
causes that sub-component to be parsed but not deployed.
e.g.
X extends PrimImpl {...}
Y extends PrimImpl {...}
Z extends PrimImpl {...}

c extends CompoundImpl {
  sfClass "myCImpl" ;
   x extends X ;
   y extends Y ;
   z extends LAZY Z ;
}
Again, from what I understand so far (possibly incorrect), x and y will 
be parsed, deployed and their lifecycles synchronized, whereas  z will 
be parsed  but not deployed. In order for it to be deployed, myCImpl 
needs to retrieve the  ComponentDescriptionImpl  for z and  use 
sfCreateNewChild  to  deploy an instance of  z. This instance will have 
a lifecycle, but that lifecycle will not be synchronized with the 
lifecycles of x and y. (c.f. SmartFrog tutorial, section 10, Dynamic 
Deployment).

2. Given this, I was having a look through the HelloWorld example where  
a Generator component contains a Printer component as a LAZY subcomponent:
Generator extends Prim {
 sfClass ""GeneratorImpl" ;
 frequency 10 ;
 messages ["a", "b"] ;
 // printer LAZY ... ;
}

The GeneratorImpl class accepts a Printer  object instance which is  
obtained by a  call to sfResolve:
Printer printer = (Printer) sfResolve(printerRef) ;

In looking at the GeneratorImpl implementation, given that it accepts a 
LAZY component, I was expecting to find some code in which the 
ComponentDescriptionImpl was retrieved and a child component allocated, 
as in the dynamic deployment example. However, I didn't find such code.  
Now i'm wondering why, given that a LAZY component is parsed  but not 
deployed.

I suppose my questions are:
(i) why is the dynamic deployment pattern not used in the HelloWorld case
(ii) who is deploying the Printer component
(iii) what is the recommended manner in which to deal with components 
which include LAZY subcomponents

Richard