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