On 05/11/10 05:11 PM, jean.mccormack wrote:
>
> I think we'll stick with what was used in the prototype, which means it
> would be more like:
>
> TD = register_checkpoint("target discovery", td.discover,
> TargetDiscovery) # name, path, func
> TI1 = register_checkpoint("instantiate ips", ti.instantiate, <func name
> to instantiate TI ips object>)
> TI2 = register_checkpoint("instantiate cpio area", ti.instantiate, <name
> to instantiate TI cpio object>)
> Xfer 1 = register_checkpoint("Xfer IPS", transfer.transfer, create_transfer)
> Xfer2 = register_checkpoint("Xfer CPIO", transfer.transfer, create_transfer)
>
> I'll use transfer to explain what goes on here. During
> register_checkpoint for Xfer 1, create_transfer is executed.
> This function will grab the cache and look at the checkpoint node for
> "Xfer IPS" (get_child_by_name call into doc)
> which is created prior to this call. This node will have the type of
> transfer as an attribute. create_transfer will read that value and
> instantiate, in this case, a transfer IPS object and return it. So Xfer1
> is a transfer IPS object.
>
>> - Each checkpoint should have a defined "interface" in that it would define
>> what it takes in (via the DOC) and what it outputs (via the DOC).
>>
> Yes. That is part of each spec.
OK
>> As such, I would have thought that setting td_node.dst would be
>> unnecessary
>> since it would be the default for TD.
>>
> Only if there is a default. Again, that is an interface to be defined
> but there
> might be a case to make it programmable. That belongs in the checkpoint
> specific design. Let's just say that somehow the app knows where that data
> is, either because it's in the default location or because it told TD
> where to put it.
Fair enough...
>> In the case of TD, it would have no input parameters, but would, by
>> default,
>> output a tree of discovered targets into the DOC. This would be a part of
>> the "well-known and documented" interface.
>>
> Again, maybe on the input parameters. TBD.
>>
>>> # Now execute engine just running TD:
>>> execute(TD)
>>>
>>> # And now we need to add information to other nodes
>>> ti_node1.create = ... # root node of some tree of nodes that the App
>>> wants
>>> ti_node2.create = ... # root node of some tree of nodes that the App
>>> wants
>>> xfer_node1.src ="http://some/ips/repo:port";
>>> xfer_node1.dst = "rpool/jean/pkg_imag" # image area for IPS to
install to.
>>> xfer_node2.src = "/"
>>> xfer_node2.dst = "rpool/jean/whatever" # area to cpio to
>>>
>> I'm really wary of objects being used like this - for example, if at anypoint
>> the application does a roll-back to a previous snapshot, in-process, then the
>> objects in the DOC will be different to the objects being used above.
>>
>> As such, the use-case for anything stored in the DOC should be along the
>> lines
>> of:
>>
>> ti_node1 = doc.get_child_by_name( "TI_IPS" );
>> if ti_node1:
>> ti_node1.create = ...
>> else:
>> # handle no entry, by either creating one, and inserting it or raising
>> # an exception if it should be there.
>>
>> If you don't do this, then there is a real chance of things not working as
>> expected.
>>
>
> And we could even wrap this into something like a method
> add_data_to_cache()?
If you wish - as long as you get the data from the cache as opposed to holding
a private reference to it, then I'm happy.
>
> Better?
Yep, thanks.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
