- From: Greg Stein <gstein@lyra.org>
- Date: Tue, 19 Dec 2000 23:24:41 -0800
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
- Cc: ietf-dav-versioning@w3.org
On Tue, Dec 19, 2000 at 05:55:16PM -0500, Geoffrey M. Clemm wrote: > From: Greg Stein <gstein@lyra.org> > > On Tue, Dec 19, 2000 at 03:50:36PM -0500, Geoffrey M. Clemm wrote: > > > > (1) Should version history URL's be in core (i.e. be required)? > > Prefer no. > > I don't have the mindset for a "core" server, so I'm not sure why this would > be needed. > [ as Boris pokes fun :-) ... yes, I need it for a REPORT, but that is it. ] > > Well, actually, anyone that implements versioned collections will > end up providing version history URL's because each member of a > collection version is a version history. Only if you allow "slashing-through" a collection version resource. :-) This does imply that a core server would not implement collection versions. > So if /repo/ver/73 is a collection version with three members named > a, b, and c, then /repo/ver/73/a, /repo/ver/73/b, and /repo/ver/73/c > are all version history URL's. That's the theory :-). Honestly, I probably won't be allowing that in the first revision. I've got enough to do as it is... > With this in mind, do you want to reconsider your "prefer no"? > (I.E. why would you prefer we not require something you are planning > on doing :-). We're talking about putting them into core, not whether I'll be implementing them. :-) Version history seems a relatively complicated beast, so making it core seems like it would need a justification. Therefore, my "prefer no" and a request for why a core server would *need* them. >... > (And also note that working collection members will be initialized > to be version history resources, just to bang that drum one more time :-). Sure, but that isn't the question at hand, now is it :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Wednesday, 20 December 2000 02:21:41 UTC