[cddlm] Reply to Steve's comments on the Component Model

[Stuart Schaefer]

Steve,

 

Here are some thoughts on your comments on the Component Model.

 

 

1) Each component object is a new instantiation of a component.  Are you
asking whether the component model is smart enough to recognize that
another instance already exists, and not create a new instance?  That
seems to me to be a higher level primitive than the component model, but
could be handled if necessary.

 

2) I will try to add language to define that we are deploying anything.
The point of the services assumption is that this is Grid Forum, and we
are trying to deploy grid services somewhere.

 

3) Resource responsible vs. hosting.  I received feedback on that
before.  WS-RF and WSDM define logical vs. physical resource in such a
way that does not require hosting.

 

4) All internal use of documents is supposed to be CDL.  it is specified
that way in the Foundation document and in the CDL language document.
There is a uniform resolution process.  There is also a means to pass
the CDL document to a component.  In that way, components don't have to
be written to read multiple languages.  They are parsed by front-end
parsers.

 

5) The lifecycle diagram does not match yours.  You do allow termination
from initialized.  SmartFrog does not.  My presumption has been that you
can accept the terminate, and march the commponents through their
lifecycle.

 

6) If the code base of an object is a remote URL, does the component
have to load the object itself?  Who is going to do the fetch or upload
operation?

 

7) Synchronous vs. asynchronous state transition operations.  There will
be lots of extra code and failure handling for asynchronous, event
driven state transitions.  I am fearful of either approach.  Synchronous
is easier to define :)  I will look at the Deployment API and see how it
is at odds.

 

8) I am very confused by your "very, very, very slow" comment.  It seems
you are agreeing with me, and showing how you handle this case with
SmartFrog.  is that right?

 

9) Why shouldn't external components declare dependencies on children of
delegates?  A delegate is defined to manage the lifecycle of a child
component.  Thus, a delegate is free to manage that lifecycle in any way
it sees fit.  If you declare a dependency on the child component, the
delegate is no longer free.  It must be careful not to violate that
dependency.  I don't think you can have it both ways.

 

10) Read-on-run vs. read-on-initialized.  My intention with the
statement was to remind implementers that resolution is not
instantaneous.  Thus, if you wait until you need it, your deployment
operation may slow down.  However, I see your point as well.  I will
change the language, but add the reminder.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/cddlm-wg/attachments/20050427/af85e894/attachment.htm