Next message: Tim Ellison OTT: "Protected properties"
Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B015@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Thu, 24 Feb 2000 21:57:18 -0500
Subject: RE: Enumerating repositories and workspaces
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> There are also systems that do not require repositories. I
> think the server
> implementation should hide these details and they shouldn't
> appear in the
> protocol.
Repositories (like activities, configurations, and workspace
resources) are part of the advanced versioning protocol and
therefore are optional (i.e. available if your system requires
them). This is how we achieve interoperability at a level above
the "lowest common denominator".
Since which repository contains a versioning resource
(versioned resource, configuration, activity) can determine what
relationships the resource can have with other
versioning resources, it is something that must be under explicit
control by the client.
If your server provides multiple repositories (which many servers
will do), then it makes sense to provide some interoperable way for
a versioning client to discover the two key pieces of advanced
versioning metadata, i.e. the list of known repositories and the
list of known workspaces. The natural way to provide this information
would be with a DAV:workspaces REPORT and a DAV:repositories REPORT.
Saying that the user will somehow find out this critical information
with some non-standard, non-interoperable mechanism will severely
(and unnecessarily) limit the utility of WebDAV for those servers.
If when the versioning protocol reaches draft standard, DASL is
sufficiently mature to be counted on to provide these reports,
I'd be happy to remove them from the versioning protocol.
> In general, WebDAV gives a lot of server flexibility, and servers may
> provide WebDAV capabilities with other restrictions. OPTIONS
> covers some of
> this, but not all. It will be difficult if not impossible to
> specify all
> these instances now and capture them in the protocol.
John isn't asking for something complex here ... just a list of the
known workspaces and repositories. Since repositories contain all
the other versioning metadata, this is all he needs to efficiently
access arbitrary versioning metadata.
Cheers,
Geoff