ant elder wrote:
I'll respond to this in two separate replies as there are two things
you're asking about.
On Thu, Jul 8, 2010 at 7:14 AM, Jean-Sebastien Delfino
<[email protected]> wrote:
<snip>
I'm puzzled as well with the logic in stop(), which now calls node.stop() +
factory.stop() + removeFromDomainLevelComposite(). For me starting /
stopping components in nodes is really orthogonal to adding / removing
composites to / from the domain.
The stop command has three variations depending on the arguments:
1) stop contributionURI compositeURI
2) stop contributionURI
3) stop
In (1) that will stop a running composite which is the same as the
stop command you had with the difference that your original start
command could give the deployed composite a label like "nodeA" and
then use that label on the stop.
Right that label is the name of a node, I'd like to keep it to be able
to list nodes and their status, or stop or restart nodes without having
to remember what contribution and composite they're running.
The old start used the composite
qname
I didn't have the composite qname in the old start, just node-name,
contribution uri, contribution location.
this one uses the composite uri and that matches the operations
describe in the spec, and when using start contributionURI composite
URI you don't really need another label for that.
Well, I do, like I said, that's a node name, and I want to use it to
control the node.
We could add the
other way too i guess, is that something you feel strongly about?
I like to have this node name. That's why I had put it there in the
first place.
The (2) format stops a contribution and all its running composites,
(3) stops everything and shuts down the shell which is the same as
your 'bye' command, the bye command is still there doing the same as
the noarg stop. Are you sayng you'd prefer the noarg stop command is
removed and only have bye?
I don't understand why stop would exit the shell. In my view there can
be multiple nodes in a shell, you can start/stop them individually,
start/stop all of them, but that's different from exiting the shell.
I don't understand either why the stop command would call
removeFromDomainComposite... If stop just stops a runtime instance, it
shouldn't really affect the domain composition...
So there's a disconnect here... I'm starting to sense that your new
concept shell is actually very different from my original shell sample,
and perhaps this is the disconnect.
I had multiple runtime nodes in a shell, but no concept of a domain at all.
Your new shell is really a domain shell, attempting to support SCA
domain operations. Perhaps that's why your start / stop commands call
addToDomainComposite / removeFromDomainComposite, and also why you have
a single Node2 node from module domain-node...
Implementing an SCA domain shell, to allow an administrator to manage an
SCA domain, is a fine idea and something Tuscany should do IMO, but my
goal with the launcher shell was much less ambitious, and pretty
different too: just support starting / stopping runtime nodes, which
would just get the SCA contributions from an SCA domain managed separately.
In summary, my perception is that samples/launcher-shell was just a
runtime node launcher shell, and modules/shell is really an SCA domain
manager shell. Both should co-exist IMO, as separate tools, perhaps as
modules/domain-shell and modules/node-shell if people want to make these
tools mainstream in Tuscany.
I think we should revert back to specific parameters on the command methods,
like you still have on start() instead of just a list of toks like you now
have on stop(). Passing the list of toks defeats the purpose of the eval()
method.
Seems like an implementation detail but fine. Passing in toks made it
easy to handle optional arguments but either approach is ok by me.
--
Jean-Sebastien
