The URI proposals so far specify URIs which are
just as parseable as those currently in use by maven's
repository [1].
The only caveat is that they need to be parsed
from right to left, as the organisation [2] part of
product-specifier cannot be separated from the directory
part of access-specifier, without prior knowledge of
the repository structure.
E.g: if a repository has its root at:
http://www.apache.org/repository
And the organisation of a project is:
org/apache
And the project name is:
commons-cli
The URI:
http://www.apache.org/repository/org/apache/commons-cli
needs to be parsed from right to left to determine that
the project is commons-cli.
Without knowing that the repository has its root at:
http://www.apache.org/repository;
the organisation cannot be determined.
Like maven's repository, which doesn't impose any
version naming convention, tools trying to parse
the URI need to make guesses as to which version
is older or newer.
-Tim
[1] http://www.ibiblio.org/maven
[2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Noel wrote:
You don't have to like the tool, I'm not trying to push the
implementation
I've never even seen the thing, and you are a priori assuming
that I don't
like it?
No Neol, I'm not that emoition, I meant it dispassionately and without
inference, maybe it just read differently. That was more 'one'
doesn't have
to like it. [I know this list has (in the past) slipped into
implementation
codebase factions, and I was hoping not to encourage that.] So perhaps I
should've writen ... One doesn't have to like this
tool/implementation, but
the results are valuable at layer 1.
It allows you to query what is there, query and capture oldest
resources
[and do a delete/clean], and download newest, etc.
How does it know what OLDEST means? I see that Tim is trying
to add some
more structure, so maybe he's thinking that we can restrict the
URI space
so
that a restricted notion of version assures an automatable concept of
succession.
Ruper parses all the attributes of the resources, including the
version, and
either do (pchar) string comparisons or (in versions case) structured
comparisons. Much as there are a few different flavours of a versions they
pretty much fall into a parsable pattern. Ruper (through Version) strictly
parses the string in a number of different ways (known formats) until one
matches.
Again, the most important aspect of parsing the URI is knowing what is
separated from what, that this pchar is a version, this pchar is
a type (or
whatever). If values can by groked within that, great, if not, it is still
Some find such a tool useful, I'd like to believe that apache users
(admins
and external users) would find it useful.
I don't disagree. I simply said that if you view the
repository solution
as
a layer of specifications, the lowest layer can be a syntax
that does not
require semantics such as an automatable concept of succession. If we
need
that, we can add it either by a convention within the URI space, or by
other
means.
We all agree to layers, but I am testing what are the minimum things we'll
accept for layter one. I beleive that the repository needs to be 'tooling
readable', hence the URI needs to be parse, the other aspects (can an
attributed be fully groked) can come later.
Again, I need to get to the wiki to put a proposal and pros/cons, I'll try
next week.
Absolutely. But that may require something more than the URI
schema. :-)
But if it doesn't have to, should it? I'm trying to determine what we
ought will accept at the lowest level. I think clean up is important, I
like the other aspects. I agree that much should be done via
metadata (e.g.
dependencies) however writting potentially shared/conflicting files to a
repository is a scary step, and I'd like to see how much we can do with
atomic artefacts.
I feel we have the potential to win big, and I'd like the ASF
Repository to be a step forward towards these goals, not a step
backward.
I agree. But one layer at a time. :-)
Yes, and we are doing layer one -- without metadata, we still need to
determine our minimum expectations. If URI is this contentious/involved, I
could see metadata as being a long drawn out process one we
don't agree on
as a whole. Maybe this first layer is the hardest, but I'd like
it to be the
one giving the most rewards so we aren't all sitting waiting for metadata.
regards,
Adam
