Simon Laws wrote:
On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote:
On 10/30/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote:
On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote:
On 10/30/07, Simon Laws <[EMAIL PROTECTED] > wrote:
On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote:
If you've an SCANode that is already running (you've added
composites
and
started the node) and then you add additional composites there
doesn't
seem
to be any way to start just those newly added composites. I can
call
SCANode.start and that kind of works but it starts all the
existing
already
started composites as well so makes a bit of a mess duplicated
various
things. Is this something thats planed to be fixed or should I
go
ahead
and
add a way to do this?
...ant
Ant
When we discussed the domain/node API a few weeks ago there was a
suggestion that we restrict to the node so that there is no fine
grained
control over starting the individual artifacts that a node is
responsible
for. So the lifecycle is:
create node
add contributions
add composites to domain (indicate which composites are to run)
start composites
stop composites
remove contributions
destroy node
So you spend some time configuring the node then you start it.
There
have
been some changes to the code recently but I believe this is how
it
works at
the moment. I'm looking at the code now to get back up to speed.
This is an issue for both nodes and domain. .
Firstly, as you say, in the case where you are just working with a
node
you
can't add a new contribution and start it once the node is running
without
doing a stop() to stop all the running components first and then a
start()
to restart everything. The benefit of this is at least it is a
simple
model
but there may be unintended consequences of doing this. I haven't
tried
this
yet with the new code changes but I will do shortly.
Secondly, at the domain level we have provided a method for
starting
individually named composites. The intention here is that domain
finds
the
node with the named composite and starts it there. This suffers
from
the
same problem that you face if a contribution has more than one
composite
in
it, i.e. subsequent composite start requests can target the same
node.
Again
this should still work if the domain first stops the node and then
starts
it.
I'm not clear if thats saying that the intended design is that the
only
way to add new contributions to an existing domain is by stopping
and
restarting, or that this is just a limitation of the
current code?
Sorry typo in that, i meant node not domain, so:
I'm not clear if thats saying that the intended design is that the
only
way
to add new contributions to an existing node is by stopping and
restarting,
or that this is just a limitation of the current code?
...ant
Yes, that's how the node is intended to work today. However this is a
simplification strategy which means that we don't need to keep track of
what
is and isn't started in a node. There is a price to pay in terms of
flexibility and configuration performance. This means we may find that
this
isn't satisfactory and have to change so if this just doesn't work in
the
hot update web app case then we need to change our direction.
This seem to limiting to me and is a regression over what we had
previously, so I'd like to enhance it to support adding contributions to a
running node. Happy to take suggestions for this but otherwise I'll just
add
code to the SCANode interface.
...ant
Well the conversation on the list turned into a code exercise to get a
better view of what works and what doesn't. So I would say go ahead. It'll
give us a better view of what functions are really required rather than just
what we think are required.
Simon
My view is that the node should be as simple as possible:
- limited to one composite
- limited to the set of SCA contributions required to run the composite
- recyclable, a node can be reset to run another composite
And then a server, a domain can be built out of many small nodes.
We've been going through this several times already with different
versions of the domain+node API and implementations, but for some reason
we seem to be very quick at turning the node into a small application
server, running multiple composites, multiple independent contributions,
with lifecycle management for these composites and contributions,
in-memory wiring and re-wiring with composites coming and going etc.
This may be very well be a valid approach but I'd like to explore the
"simple single-composite node".
How should I do this? Should I create a new SCASimpleNode or
SCALimitedNode to let you add the more sophisticated features you need
to the SCANode? or can we try to keep SCANode really simple for a while?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
