On 10/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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?
Not sure if I completely agree with all that but I guess I can't seem the harm in having a SCASimpleNode if you want that while things are still evolving. And then before 1.1 we can review where things are at and refactor as appropriate. ...ant
