Re: A question on Versioning-unaware clients
Chris Kaler (ckaler@Exchange.Microsoft.com)
Wed, 6 Oct 1999 15:39:03 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD940@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>, ietf-dav-versioning@w3.org
Date: Wed, 6 Oct 1999 15:39:03 -0700
Subject: RE: A question on Versioning-unaware clients
It seems to me, that if a server supports multiple protocols,
then a "PUT" via a non-versioning-aware client/protocol, should
be treated "always" as automatic versioning.
Otherwise I would argue that the version store's integrity has
been compromised.
Maybe we can make everyone happy by just adding a sentence that
servers that support multiple protocols, must uniformly reject
PUT requests or uniformly support automatic versioning.
What do people think?
Chris
-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Thursday, August 05, 1999 11:29 AM
To: ietf-dav-versioning@w3.org
Subject: RE: A question on Versioning-unaware clients
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