> > 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
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
> > 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
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
> 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
> > 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.