Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:06:50 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:06:50 -0800
Message-ID: <005201be7ca5$16927e60$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Monday, March 15, 1999 9:54 PM
To: ckaler@exchange.microsoft.com
Cc: jamsden@us.ibm.com; ejw@ics.uci.edu; dgd@cs.bu.edu;
Cragun.Bruce@gw.novell.com; bradley_sergeant@intersolv.com
Subject: Re: Version issues
The protocol will let you treat a workspace as merely a checkout token
(with no revision-selection-rule). The only exception is the default
workpace, which has a single revision selection rule indicating how
you want the default revision computed. A server can make this
default workspace revision selection rule read-only, so that the
server doesn't have to implement more than one built-in default
revision selection rule (e.g. "label=default").
How does this require any more from the server than you already
have it provide?
Cheers,
Geoff
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
If I want to view a document store as a file system, I don't care
about workspaces. I want to version my documents, like I do, say
in the VMS file system. I don't want to think about workspaces.
If I am tracking the information on the client I don't necessarily
want it tracked on the server. I might have a good reason, e.g., I
don't want to waste server resources or time.
The model needs to accommodate these.
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Monday, March 15, 1999 10:33 AM
To: Chris Kaler (Exchange)
Cc: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; Chris Kaler (Exchange);
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues
[CK2] Two points - and they represent different customer segments.
(1) This isn't my model. I have lots of unrelated documents
and, as a level 1 client app, this complicates everything.
(2) There are cases, NT for example, where workspaces will have
real scalability problems. I may want/need to manage the
state on the client not the server.
How do workspaces complicate things and for whom? I agree they make a
little more work for servers to do the revision selection, but I think
it's
better to have that complexity in the server not the many clients that
access the server. You get much better reuse and simplify what clients
and
users have to do. Isn't that a good thing?
Also, just because there's workspaces doesn't mean a client can't
implement
its own model with labels, properties, other resource types, etc.
Workspaces aren't a restriction for clients, they're a service.