Next message: Geoffrey M. Clemm: "Re: Versioning TeleConf Agenda, 4/10/00 (Monday) 2-3pmEST"
Date: Mon, 10 Apr 2000 23:43:03 -0400 (EDT)
Message-Id: <200004110343.XAA10282@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Stable URLs
From: jamsden@us.ibm.com
1. As Tim pointed out yesterday, why are we even considering these
stable URLs for down-level client support? Why isn't this just a
client binding issue? If a down-level client wants a stable URL to
access revisions of a versioned resource, some other versioning
aware client could provide them through bindings. Some versioning
clients may even do this automatically. I don't see why the server
and protocol need to get involved in this kind of policy
issue. Workspaces and revision selection, plus bindings provides
everything needed.
Many versioning implementations do not support a BIND operation.
Those that do support it often only support a BIND to a versioned
resource, not a BIND to a particular revision of a versioned resource.
But they all give you some way of getting to a particular revision of
a versioned resource. JimW wants us to require that a core versioning
server provide a URL that gets you to a particular revision, so
that versioning unaware clients can get to a particular revision.
I am still unconvinced that this must be a core feature, since if it
is so important, the servers that provide it will rapidly dominate
those that do not, but on the other hand, I haven't heard any good
arguments for why it would be *hard* for a core versioning server to
provide this functionality, so I'm inclined to vote to leave it in
core versioning until I hear such an argument.
2. Where does the protocol actually require these stable bindings
for its own purposes?
I'm note quite sure what you mean by "for its own purposes".
The main argument for stable bindings is to ensure that versioning
aware clients can expose multiple revisions of a single versioned
resource to versioning unaware clients.
3. If we have to have stable bindings (note I'm using that term now
as I still think servers need to be free to impliment and
reorganize their stores independently of the WebDAV protocol), then
why not have the "human" URLs be live properties accessed through
the stable bindings instead of using a report?
Because each workspace potentially has a different "human" URL that
identifies a given versioned resource, so the "human" URL is a function
of both the stable URL and the workspace.
Cheers,
Geoff