Next message: jamsden@us.ibm.com: "IETF 47 Delta-V Working Group Notes"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568BA.00057E71.00@d54mta03.raleigh.ibm.com>
Date: Thu, 6 Apr 2000 20:59:57 -0400
Subject: Re: Stable URL's for working resources?
OK, sounds good.
From Geoff Clemm
I'd like to remove the requirement that a workspace resource
provide stable URL's for its working resources.
The problem is that many/most implementations don't store the
working resources in a repository, but rather in a simple file
system tree. So although it is reasonable to expect an
implementation to maintain stable URL's for the versioning
metadata such as revisions and activities, it is not as reasonable
to expect it to maintain them for working resources. Since the
whole point of a working resource is for it to be mutable,
requiring it to be identifiable via an immutable URL is not what
one would expect in any case.
The only change that this requires to the protocol is to change the
definition of the DAV:working-resources property of a workspace
resource to no longer require that the href's contain "stable
URL's".
From: jamsden@us.ibm.com
I'm OK with this, but workspaces should not be concerned with
implementations that store resources locally in the client file
system. This is purely a client issue for optimizing access,
supporting file-based access to resources, and supporting
disconnected work.
I wasn't referring to storing resources locally in the client
file system (I agree that is out of scope of the protocol), but
rather for servers that are designed to support thousands of
workspaces, and do so by maintaining a server farm, each of which
contains some number of workspaces. The "file system tree" was
a reference to a common server side implementation technique.
Since many server extensions require the instantiation of resources
in a file system tree, the file system implementation is a key one.
Even for non-file system implementations, the general principle of
decoupling a workspace as much as possible from the shared versioning
repository will be a key element of scaling and performance.
Cheers,
Geoff