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
