On Tue, Feb 26, 2008 at 5:57 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On Mon, Feb 25, 2008 at 4:17 PM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > >> Jean-Sebastien Delfino wrote: > > >> Looks good to me, building on your initial list I added a few more > > items > > >> and tried to organize them in three categories: > > >> > > >> A) Contribution workspace (containing installed contributions): > > >> - Contribution model representing a contribution > > >> - Reader for the contribution model > > >> - Workspace model representing a collection of contributions > > >> - Reader/writer for the workspace model > > >> - HTTP based service for accessing the workspace > > >> - Web browser client for the workspace service > > >> - Command line client for the workspace service > > >> - Validator for contributions in a workspace > > >> > > >> > > > ant elder wrote: > > > Do you have you heart set on calling this a workspace or are you open > > to > > > calling it something else like a repository? > > > > > > > I think that they are two different concepts, here are two analogies: > > > > - We in Tuscany assemble our distro out of artifacts from multiple Maven > > repositories. > > > > - An application developer (for example using Eclipse) can connect > > Eclipse workspace to multiple SVN repositories. > > > > What I'm looking after here is similar to the above 'distro' or 'Eclipse > > workspace', basically an assembly of contributions, artifacts of various > > kinds, that I can load in a 'workspace', resolve, validate and run, > > different from the repository or repositories that I get the artifacts > > from. > > -- > > Jean-Sebastien > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > To me repository (in my mind somewhere to store things) describes a much > less active entity compared to the workspace which has to do a lot of work > to load and assimilate information from multiple contributions. I'm not sure > about workspace either but to me it's better than repository and it's not > domain which has caused us all kinds of problems. > > My 2c > > Simon > I started looking at step D). Having a rest from URLs :-) In the context of this thread the node can loose it's connection to the domain and hence the factory and the node interface slims down. So "Runtime that loads a set of contributions and a composite" becomes; create a node add some contributions (addContribution) and mark a composite for starting(currently called addToDomainLevelComposite). start the node stop the node You could then recycle (destroy) the node and repeat if required. This all sound like a suggestion Sebastien made about 5 months ago ;-) I have started to check in an alternative implementation of the node (node2-impl). I haven't changed any interfaces yet so I don't break any existing tests (and the code doesn't run yet!). Anyhow. I've been looking at the workspace code for parts A and B that has recently been committed. It would seem to be fairly representative of the motivating scenario [1]. I don't have detailed question yet but interestingly it looks like contributions, composites etc are exposed as HTTP resources. Sebastien, It would be useful to have a summary of you thoughts on how it is intended to hang together and how these will be used. I guess these HTTP resource bring a deployment dimension. Local - Give the node contribution URLs that point to the local file system from where the node reads the contribution (this is how it has worked to date) Remote - Give it contribution URLs that point out to HTTP resource so the node can read the contributions from where they are stored in the network Was that the intention? Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27362.html
