Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:04:55 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:04:55 -0800
Message-ID: <004d01be7ca4$d1eb6ba0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Chris Kaler (Exchange) [mailto:ckaler@exchange.microsoft.com] 
Sent: Monday, March 15, 1999 9:47 AM
To: 'Geoffrey M. Clemm'
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



Philosophically I don't have a problem with this.  I'm just concerned 
about what it means to have a workspace behind the token.  As I have 
stated a couple times, I can see cases where storing the "state" on 
the server scales worse than storing it on the client.  I would rather 
say that a check-out results in a "token".  That could be a workspace
or just a token.  

I want to allow for the application that wants to track what "workspaces"
track, but on the client, not the server.

Chris

-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Friday, March 12, 1999 8:47 AM
To: Chris Kaler (Exchange)
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


I have a different response from JimA.  In particular, I would not
say "checkout tokens are bad" but rather "a workspace *is* a checkout
token".

Let's try an analogy.

A level-1 identity-card (workspace) has your picture and your name
printed on it.  You can use it to prove you are who you say you
are (get a working resource).

A level-2 identity-card is just like a level-1 identity-card, except
it also has a magnetic stripe (revision-selection-rule) encoding
credit-account information.  You can use a level-2 identity-card
wherever you would have used a level-1 identity-card, but you can
*also* use it in bank-teller machines, etc.

By default, the magnetic stripe just has "no valid account" encoded in it.
So a default level-2 identity card acts identically to a level-1 identity
card.

Now what's the world like from a level-1 client's perspective?
He gets an identity card from either a level-1 or level-2 server,
and he uses it to prove his identity, for which either a level-1
or level-2 identity card works just fine (nice and interoperable).

How about from a level-1 server's perspective?
He just keeps printing pictures and names on plastic cards,
just as always.  No problem.  This is the key point.  The fact
that a level-2 server puts more stuff on the card has *no*
impact on the level-1 server.

So it's no additional stress on a level-1 client or server,
but a level-2 client gets a *big* benefit, because he can use
his level-2 identity-card *everywhere* (i.e. at both level-1
and level-2 servers) to prove his identity.  Otherwise he has
to carry around level-2 identity cards for level-2 servers
and level-1 identify cards for level-1 servers (and remember
which server is at which level).

Cheers,
Geoff

   From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>

   How is a checkout-token different from a workspace that has
   no revision-selection-rule property?

   [CK] The difference, to me, is this.  A checkout-token represents
	a single thing.  It refers to a working copy of a specific
	revision of a specific resource along a specific line of descent.
	A workspace represents multiple resources and likely involves
	additional persisted state to represent the workspace.
	If I have a client that knows how to manage tokens, I don't
	want to have additional server state to track what I am
	already tracking.