one of the issues with the descriptor approach is bandwidth.
How does the tool fetch an artifact using only the descriptor approach and
minimal URI usage:
a) Contact repository and fetch information on components available.
Imagine it's similar in size to ibiblio  and under 50K.
b) Contact repository to retrieve descriptor for Component C. Size unknown.
Imagine it's something like Jelly, at 100K+ for raw HTML  and XML will
c) Parse/xpath the xml document for version details
c) Contact repository for jar, worst case an oft used small jar like
Net result: 3 HTTP connections, 1 SAX Parse, 210K download for a 60K jar.
I'm not saying this is typical, but now multiple it by a few thousand, and
ask yourself how well it scales.
dIon Gillard, Multitask Consulting
-----"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: -----
To: <[EMAIL PROTECTED]>
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
Date: 03/09/2003 05:07PM
Subject: RE: What does the repository enable?
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
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 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