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. > > Simon > > I have found a snag with the starting/stopping approach which I'm just fixing now. I'll check in a fix shortly.
Simon