www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: What does the repository enable?
Date Sun, 09 Mar 2003 06:07:30 GMT

Essentially, I view the repository as sort of UDDI for components, except
without the ontological concepts.  In other words, the purpose for the
repository is to provide a federated component directory.  Within that
directory is published information about the component, such as the type of
information needed to build, download and/or deploy each component.

This is why I'm in the XML descriptor camp, not the
encode-everything-in-the-URI camp.  For the most part I think that a lot of
the arguments over the URI miss the point in the first place.  For any given
entity, I think that there should be an unchanging URI that provides access
to the descriptor.  Versions, etc., are described within the descriptor.

If I want to download version V of component C (C[V]), I use the URI for C,
get the XML descriptor, find the information for version V, and that tells
me where to get the component.  I couldn't care less what the URI is for
C[V], any more than I care what a mirrored URI is for downloading httpd.
Nor do I care if changes.  When I need a URI to download the component, I'll
get it.

I do like the ideas that have been put forth about recognizing the type of
requester, so that a user gets some nice HTML, and a tool gets the XML it
needs.  And I've made suggestions that a smart repository could accept
parameters on the URI so that only the portions of the descriptor needed to
satisfy the request could be returned in the response.

I agree with your list of items (and Costin's additions), except that they
should be generalized, not Java or jar specific.  I gave an example of a
single application that was built from java, binary and CPAN.  If we can
satisfy the broader needs, we have a much better chance of getting the
repository adopted.  And if we just stick with what we already have decent
understanding, and not try to invent lots of new wheels before we get
started, this repository is realistic.

We have GUMP, Ant, Maven, and JNLP to view for prior art, as well as RPM,
debian, BSD ports, and other technolgoies.

I hope that Andrew is reading, and I'm keen to see his comments.  I did see
that he posted some XML earlier in the week, which I'll take a look at over
this weekend.

	--- Noel

View raw message