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
