On Tue, Jul 13, 2010 at 5:56 PM, Simon Laws <[email protected]> wrote: > Some more comments in line. > > To prevent this discussion being too theoretical and long winded it > would possibly be appropriate for those of us who have been working on > this stuff to try and phrase the scenarios that are important to us in > terms of how existing (or possibly new) interfaces would be used. I'll > have a go when I've got my act together. > > Simon > > On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino > <[email protected]> wrote: >> Raymond Feng wrote: >>> >>> Hi, >>> >>> We had a debate on this topic. See: >>> >>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html >>> >>> And apparently, we didn't reach agreement. >> >> It's probably a good idea to restart that discussion and find a consensus on >> this. After having not looked at the Tuscany code for a while I must admit I >> was a little confused by the multiple Node types. >> >> I'll try to participate in the discussion as much as I can, although I have >> little spare time these days. In the meantime, I'd like to continue to use >> the mainstream Node implementation for some time in samples/launcher-shell, >> as it's what's working with webapps, all the test cases, samples etc. >> > > I haven't got my head round these either yet, for which I apologize, > but it seems sensible to try and support something that looks like the > features that the spec describes. We do need to agree where it lives > and how it enables us to populate our picture of the domain and > subsequently how this gives rise to the running of configured nodes. > >>> >>> I think it would be a good idea to agree on the commands for shell. This >>> will help us understand how users use SCA. Then it can be translated into a >>> set of API/SPIs. Mixing different steps into one layer could prevent us from >>> seeing the complete user story. >> >> And like I tried to say in another email in this thread, I think we should >> distinguish: >> - Domain management, assembling components in a domain; >> and >> - Runtime instance configuration and management, loading a contribution in a >> runtime instance and starting/stopping it. >> >> They are really different IMHO, for example an SCA domain administrator can >> spend a day assembling components in a domain before starting a single >> runtime instance, and stopping a server doesn't mean that he's removing a >> composite from the SCA domain... > > There are two extremes here I think that we are touching on. > > 1/ The process of bringing all the contributions of the domain > together is completely separate from the actual starting of the nodes > that run the separate composites of the domain. In this case some tool > (even csh or explorer or a gui tool) could be used to pull together > the required contributions and ensure that everything is present. Once > done someone will use a separate tool (the command line shell) to > start the nodes to run the separate parts of this domain. I've > purposely not defined here how the nodes are configured. > > 2/ The case where the domain is constructed on the fly by running > sepearate nodes which "join" the domain and exchange information about > the services they provide. > > You may actually consider that 1 and 2 are the same thing where in 2 > the process of readying the contributions for the domain is out of > band and simply not discussed. > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
Thats all very useful but i think its a slightly different topic - one thing that was wanted here was a way to create an isolated Node instance thats _not_ part of any domain, so yes there's lots of different ways we can have for building a domain but don't have any API for creating standalone Nodes. ...ant
