On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote: > > 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 > The simple node approach has been working well in the case where the domain is in charge. It presents a problem if you want to control the world from a single node and run multiple composites that are added/started incrementally in a single JVM.
This is not a question about the details of the API though but about what a node is for (which then of course dictates the API). If we feel a node is sufficiently lightweight that we can pop one into existence when we need to run a composite then that is good but is a different mindset from the one that says the runtime is sufficiently heavyweight that we have to be able to reuse it and hence load it up with many composites. I suspect that where we each sit in the 1 composite per node vs n composites per node spectrum is coloured by our perception of how many resources it takes to start a node. I have no evidence one way or the other but I would like us to be slick enough to pop up a node when one is required if nothing else as an aspiration to create as light a weight runtime as possible. I not so concerned that there is a new method in the API now if it gets the hot update function up and running today assuming that it doesn't break the current function. This gives us a platform to see how it works and rejig it as appropriate (including removing the new method if possible) over the next week or so. I am toying with the idea that these contributions/composites in this case should be managed through the domain proxy which has access to the local node but it's not a fully formed though yet. Simon
