Nick,
My apologies for reformatting your reply, but I thought that it made sense
to rename the thread, and still keep the context intact.
How did you perceive my strawman to be incompatible with a filesystem only
approach? If the URI for an addressable entity results in an XML file, for
example, than a file system only repository would delivery the contents of
that file. Now, should you happen to be using a dynamic server, you could
modify the response to only deliver content requested.
Consider this: if I have the XML descriptor for a given entity, I can look
in it for the particular version I care about, using the version labeling
used by that project, and find a currently valid URI to download the package
over an appropriate transport. This can be done entirely by the client
tools. Of course, if the server were smart enough to understand a more
specific request, it could hand me just what I want to know, and not force
me to have to parse as much, or even adjust a mirror list based upon
geo-matching and some request balancing heuristics.
To replicate the server, you could use rsync. Whatever is there is moved.
The server doesn't actually have to care about the structure. The real
structure is encoded in the contents of the descriptor files. Actually, a
better way of saying this is that the structure of the repository could be
decoupled from the structure of the file system. In my mind, only client
tools are required to understand what the descriptors say about the
repository structure; the repository server understanding it is a bonus.
This also removes the need to agree upon anything related to the
downloadable file names. You don't have to agree on
project-subproject-developer-lunarphase-version-platform.ext. The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
This should allow federation with other repository systems, e.g., CPAN, if I
am not missing something key. So if I had a project that used BSF and some
hypothetical perl engine, I could have a descriptor that told the tool to
grab the BSF and perl jars using that scheme, a platform-specific perl
engine (hypothesizing that the perl engine would be a JNI bridge) from
elsewhere, and Perl modules via CPAN. So this approach should be totally
agnostic with respect to tools, languages, projects and platforms.
I'm not saying that this is a great idea, just that it sounds good to me so
far. I'm keen to hear what others say about it.
--- Noel
-----Original Message-----
From: Nick Chalko [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 14:54
To: community@apache.org
Subject: Re: [proposal] daedalus jar repository
Your approach seems very powerfull, I like it.
I was trying for a "Valid" repositry being just a filesystem. I think
we can add the rest later as optionl support elements.
A filesystem only approach lets other people build "compatible"
repositories without tools or keeping a catalog.xml or whatever uptodate.
--
Nick Chalko
-----Original Message-----
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 14:46
To: community@apache.org
Subject: RE: [proposal] daedalus jar repository (was: primary
distribution location)
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]
