On Thu, May 12, 2011 at 5:13 PM, Simon Laws <simonsl...@googlemail.com> wrote: > I think having a web page to access the domain is a great idea. I'd > like to see a more comprehensive URL space support in the future. For > example, this is what came to mind when I actually sat down and put > pen to paper. > > http://somehost:someport/sca/ > {domainname}/ -> get the service document, i.e. > links the following collections > contribution/ -> get a list of installed > contributions (atom/rss?) > {contributionURI}/ -> get the contribution archive (or its URL?) > relative/uri/of/artifact -> get the artifact (see section > 10.4.1) > ?artifact=artifact identifier -> get the artifact > (identifier here could be, e.g. namespace item) > composite/ -> list of all composites in the > contribution (includes deployment time composites) > composite/ -> get a list of available composites > (atom/rss?) > spec/ -> get the domain composite as per the > spec with includes for deployed composites > exploded/ -> get the exploded domain composite as XML > {compositeQName} -> get the .composite file regardless > of whether deployed or not. Could get the GSoC picture here > ?element=xpath -> get that part of the domain > composite as XML using XPath as per policy attachment > node/ -> get the list of running nodes in > the domain (atom/rss?) > {node name} -> get the XML configuration for the named node > endpoint/ -> get the list of all active > endpoints (atom/rss?) > {endpointURI} -> get the XML representation of the > named endpoint > policy/ -> TBD >
We already have other ways to get at this information with things like the command line Shell, the programmatic DomainNode APIs, and the Maven plugin. The JMX GSoC project will likely also provide another way to get at the information. So it would be really good if where possible they all worked in similar ways providing similar commands, and also share as much code as possible. What would be the best way to that? I think its good and useful to have freedom to just play around experimenting with different commands and that will lead to finding ones we think are useful, could we then put those on a wiki page or something? For example, it looks like getting installed contributions is already on all of these, above you have: contribution/ -> get a list of installed contributions (atom/rss?) the Shell has a command "installed" which displays the installed contribution URIs on the console, and on Node there is a method doing similar: "List<String> getInstalledContributionURIs()" Can we come up with a set of commands that we all agree are useful? ...ant
