Re: A question on Versioning-unaware clients

Dylan Barrell (dbarrell@opentext.com)
Fri, 6 Aug 1999 09:57:39 +0200


Message-ID: <01BEDFF2.1ECE2A60.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>,
Date: Fri, 6 Aug 1999 09:57:39 +0200
Subject: RE: A question on Versioning-unaware clients

Definitely,

If that other protocol supports all the features of Delta-V, then you have 
no real problem. If the protocol doesn't support the features, then you 
have the same problem as you have with WebDav. I would have no problem with 
an attempt at generalising the statements we are making about HTTP and 
WebDav (i.e. non versioning aware clients) to make them applicable to all 
protocols or adding some statement at the end of the spec stating that 
other protocols should behave in the same way.

Cheers
Dylan

On Thursday, August 05, 1999 8:29 PM, Jim Whitehead [SMTP:ejw@ics.uci.edu] 
wrote:
>
> While I agree with Dylan (who was agreeing with me :-) that defining the
> interactions between FTP and Delta-V is out of scope, I suspect Som isn't
> the only person who will be having multiple protocols interacting with a
> Delta-V store.
>
> > Considering co-existence between Delta-V and another existing file
> > transfer protocol ( e.g. FTP ) is  our goal of versioning....there are
> > some possibilities:
> >
> > Possibility a:
> >
> > 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.
>
> I'd turn this around and say that, in this case, the implementation 
decision
> was to have the FTP access bypass the versioning mechanism.  As you point
> out, this has some bad interactions with Delta-V clients, and hence it's 
an
> undesirable design choice to have FTP acess bypass the versioning 
mechanism.
>
> > 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?
>
> This seem to me to be a consistent implementation of the specification. 
 If
> the underlying file is checked-out, then an FTP read operation should
> succeed on the checked-out resource, but a write operation on the
> checked-out resource would fail.  I'd also expect an FTP delete to always
> fail when operating on a versioned resource.
>
> > 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?
>
> Having all accesses to the repository go through the same interface also
> makes sense to me as an implementation choice.  But, since the Delta-V
> protocol is only concerned with how to express versioning and CM commands
> sent across a network, and is not concerned with how a server implements
> those commands (so long as their behavior is compliant with the
> specification), this implementation choice shouldn't be included in the
> protocol specification.
>
> Occasionally working groups decide to produce implementation handbooks, 
that
> detail some of these issues.  But this is a separate document from the
> protocol specification, which should be as agnostic as possible about
> potential implementation strategies (judging from the HTTP/DAV 
experience,
> people will implement the protocol in ways you have never imagined).
>
> - Jim