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

Re: Possibly Naive Question -Reply

From: Steve Carter <srcarter@xmission.com>
Date: Tue, 24 Sep 1996 16:01:20 -0700
Message-ID: <32485A30.556E@xmission.com>
To: Larry Masinter <masinter@parc.xerox.com>
CC: srcarter@novell.com, gramlich@bigbang.eng.sun.com, w3c-dist-auth@w3.org
My comments below:  -src

Larry Masinter wrote:
> 
> I've been thinking about the exchange we've had about "distributed
> editing vs reinventing file system protocol", and trying to extract
> from it:
> 
> * Which requirements for distributed editing
>   can NOT be met by a file system protocol?

I think that most (if not all) file systems will have a problem with a
presistant lock and in maintaining the ownership of that lock.
Generally, if a file system is advised that a file is to be locked to
prevent writing by anyone other that the lock holder, that lock is only
honored until the file system is restarted. This is reasonable because
the assumption is that the process editing the document will have gone
through the same state change as the file system and will therefore know
that the lock must be re-aquired. This will not be the case with
distributed authoring. The file system state will be a non-issue as far
as the authoring process is concerned. For these and the other reasons
I've stated, the working group is working toward augmenting existing
protocols to allow persistant-state (lock being one of the states)
processing of documents in a global context.

> 
> * Are those requirements explicitly described in the "Requirements
>   on HTTP for Distributed Editing" (an unfortunate title).

The intent is that the requirements be explicit. We spent several hours
on the requirements during our last meeting. Jim will soon publish the
result and I anticipate more discussion. This will be a great
opportunity for you to see where we are.
> 
> I think that most of the requirements are 'information hiding' rather
> than 'capabilities' requirements (e.g., "clients need not be aware of
> server's locking scheme in order to add a new version" is an
> information hiding requirement.)
> 
> Larry

Information hiding is only one of the aspects of the requirements. State
hiding is another. Persistance yet another. This is far from a simple
case.
-- 
-src
Steve Carter
Novell
srcarter@novell.com

At night, God leaves the lights on --
so that we know he is home.
Received on Tuesday, 24 September 1996 18:07:04 GMT

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