Re: A question on Versioning-unaware cl

Jeff McAffer OTT (Jeff_McAffer@oti.com)
Thu, 05 Aug 1999 14:25:15 -0400 

From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: SBANDYO@novell.com (SOM Bandyopadhyay), ejw@ics.uci.edu (ejw),
Message-ID: <1999Aug05.142000.1250.1278340@otismtp.ott.oti.com>
Date: Thu, 05 Aug 1999 14:25:15 -0400
Subject: RE: A question on Versioning-unaware cl


Fundamentally I believe the issue of non-HTTP clients and file access are   
extremely interesting but out of scope for the versioning work.   
 Remember, DAV (and thus Delta-V) are extensions to HTTP!  The HTTP spec   
says nothing about how/whether/if resources are organized in a particular   
server.  It doesn't, for example, say anything about things like servlets   
or live content etc. which are variations on content storage/management.   
 As such, DAV should not say anything about this.

See below for some further comments.

> I have something to say about your comment  "it's an
> implementation decision
> for the server." In this example, if FTP server chooses not
> to go thru'
> versioning mechanism, then it may allow its clients( I mean
> FTP clients ) to
> modify the file ( on which a versioning client has done a
> CHECKOUT operation
> ).
> This will result in data corruption.
> So this way, FTP & Delta-V will not be interoperable.
> Interoperability  with
> existing file transfer protocols must be our goal.
> So this can not be left for implementation.

A possible point of confusion is where we think the actual bytes for some   
revision of a versioned resource are maintained.  IMHO, it is unlikely   
that they are maintained as normal files with interesting (i.e.,   
user-defined) names.  That is, it is unlikely that a file-based program   
(e.g., FTP service) would be able to get direct access to the revisions   
of a versioned resource via the file system.  More likely is that a   
versioning server would use some sort of versioned backing store (e.g.,   
ClearCase, VSS, DB2, Oracle, ...) to store the various versions.  There   
just is no filesytem for the FTP service to access so the point is moot!

> Possibility b:
>
> [ your comment was: b) fail the second checkout (allow only
> single line of
> development) ]
>
> To provide the co-existence: CHECKOUT also performs some
> native lock semantics
> on the file. e.g in case of CHECKOUT , do a WRITE LOCK on the
> file thru'
> common
> file system interfaces. ( in that case, versioning spec has
> to include this
> semantics of CHECOUT ).
>  A FTP client then can not open the file for write purpose.
> Is this what we expect everyone to implement?

Again, it is unreasonable to expect direct file system access to   
revisions of versioned resources.

> Possibility c:
>
> Versioning component in server sits below the "common file system
> interfaces"...I mean, all access to file system from various
> clients ( e.g.
> FTP, HTTP+versioning, HTTP only, ....) will go thru' the
> versioning component.
> This is the only way one can do parallel development...
> I feel this is the best ....Should this be included in the spec?

This is a way of accomplishing what you want.  In fact, there are several   
versioning systems today which either implement a virtual device driver   
(i.e., file system) backed by their versioning store or somehow mirror   
part of the versioning store in the native file system.  There are many   
issues involved in implementing these different approaches.  Ultimately,   
they are choices made by the implementor of a particular server and are   
out of the delta-v scope.

Jeff