www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Parsable URI (Re: [proposal] URI Syntax - v0.2)
Date Sat, 15 Nov 2003 14:45:17 GMT
Noel wrote:

> > You don't have to like the tool, I'm not trying to push the
> 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
> > [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
> 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

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
> 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
> that, we can add it either by a convention within the URI space, or by
> 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
> 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.



View raw message