On 10/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > > On 10/30/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > >> > >> 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. > >> > > > > > > I'm not sure it is a perception of resource usage, the reason the > current > > webapp distro is like this is because I've not yet been able to get it > to > > work well any other way! This may well be due to limitations with the > > current SCADomain/SCANode implementations and if thats the case I'm sure > we > > can fix them as things evolve - the more things using them the more > clear > > better ways of doing things will become, but we need to get all these > things > > using it working first . I don't particularly care if there's one node > per > > contribution or multiple contributions per node as long as it works ok. > > > > ...ant > > > > > > My 2c... It'll be easier to get something clean and working ok if we > keep the node as simple as possible for now and don't try to boil the > ocean right away with multiple composites and complex lifecycle and > update management. I'll create a new SCASimpleNode as you suggested to > explore the 1-composite-per-node basic approach.
Great, say when you think its working and I'll try to move the webapp distro over to use it. ...ant
