Nick,
As long as you want to start with first principles ...
> >If we have a layout and metadata we agree on - any tool could work.
> >If it is an ant task or a perl program or we just rsync - it doesn't
> >matter.
> A somewhat standard layout is the important part.
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.
How much should be encoded in a URI, and how much in data associated with
the URI? You seem to be trying to encode all of the data into the URI
naming space. Why not have a single URI for the target, and then trigger
behavior based upon the content? That would seem more extensible and less
fragile.
This would also unify with Costin's thoughts regarding tool-neutral
standards for the repository and project descriptors. The URI tells the
repository what you want, and it responds with the information known about
it, such as the locations of its parts, dependency information, build
instructions, etc. The URI could encode optional filter information about
what we want in the response. Depending upon whether the resource were
dynamic or static, the filter might or might not be honored.
Seems to me that some of the prior art associated with JNLP should be
brought into the picture, as well as everything that Maven has learned about
repositories. And REST in terms of the web interaction.
Also, shouldn't URIs also support movement of the resource, e.g., when a
sub-project moves from underneath a project? For that matter, is the
project hierarchy really useful in the URI, or just a unique name?
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
