W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1996

RE: Seiwald Q & A

From: Yaron Goland <yarong@microsoft.com>
Date: Thu, 29 Aug 1996 12:42:07 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-44-MSG-960829194207Z-18098@mail2.microsoft.com>
To: "'www-vers-wg@ics.UCI.EDU'" <www-vers-wg@ics.UCI.EDU>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, "'Jim Whitehead'" <ejw@ics.UCI.EDU>

>1.  A fundamental component of "GET for EDIT" has to be a cookie that
>represents any stored context in the document server that needs to be
>reunited with the document on checkin.  Most, if not all, SCM systems
>are aware of their users' activity and use this awareness to keep users
>from stomping on each other's work.

I think it is reasonable for us to assume that the versioning server is 
fully aware of the user's activity. This is especially true because of the 
need for a "Currently Checked Out" function that tells a user who has the 
document checked out.

>2.  "GET for EDIT" also, mind you, has to be able to GET something other
>than the head ("tip") revision of the document.  Not everybody wants to
>start their edits with the most current rev.  And I assume we both agree
>that "GET for EDIT" means get the source, not any derived version.

The question of 'derived' entity is truly ugly. Different systems have 
different needs in this regard, especially when the 'derived' chain is more 
than one long. We normally think of 'derived' as being an HTML document and 
the source including things like server side includes. However I have seen 
longer and uglier chains. Rather than building in any assumption I am in 
favor of an arbitrary linking system where links have attributes. The 
attributes will then explain relationships.

>4.  For new documents, I think rather than a blind, out of the blue PUT
>there should be something analogous to "GET for EDIT" -- e.g. a "fake GET
>for ADD".  The primary reason for this is to support item #1 above --
>to let the document server/SCM system know what the user is up to.

I think the Check Out semantics handles this problem. Note that I am a 
proponent of having a locking system and a check out system. They are not 
the same thing and I do not feel they should be treated in the same way.

>5.  Versioning of directories is also non-sensical, for the same reason
>as #3 above.  Supporting renaming is one thing, but buying into a 
solution
>that involves versioned directories is brainocide.

As I pointed out in my document we really need to accept directories as 
real entities. Just closing our eyes and repeating "URLS are a flat name 
space" won't make the problem go away.

>6.  I think locking can be punted.  Add it in the next rev.

I would agree with Jim. From the Microsoft point of view we would rather 
see versioning punted then locking.

				Yaron
Received on Thursday, 29 August 1996 15:44:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:40 GMT