Re: A question on Versioning-unaware clients
Dylan Barrell (dbarrell@opentext.com)
Thu, 5 Aug 1999 09:28:08 +0200
Message-ID: <01BEDF24.D4D491B0.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'SOM Bandyopadhyay'" <SBANDYO@novell.com>,
Date: Thu, 5 Aug 1999 09:28:08 +0200
Subject: RE: A question on Versioning-unaware clients
FTP is out of scope for this spec. Jim's statement is the correct one -
whether you choose to implement a, b or c is up to you.
Cheers
Dylan
On Thursday, August 05, 1999 1:10 AM, SOM Bandyopadhyay
[SMTP:SBANDYO@novell.com] wrote:
> Jim,
>
> 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.
>
> 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?
>
> 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?
>
> thanks, som.
>
>
>
> >>> Jim Whitehead <ejw@ics.uci.edu> 08/04/99 04:08PM >>>
>
> > In draft-ietf-webdav-versioning-02 its mentioned that
> >
> > "Webdav versioning includes:
> >
> > automatic versioning support for versioning-unaware clients"
> >
> > My question is:
> >
> > 1. Is this applicable to versioning-unaware clients which is
> > accessing the file system thru' non-HTTP methods ( e.g. FTP )?
>
> Actually, versioning-unaware clients are HTTP/DAV clients that don't
> understand the versioning specification. Its outside of our scope to
> consider authoring via FTP.
>
> However, I can imagine a server that, in addition to implementing DeltaV,
it
> also implements FTP, and as an implementation decision, performs
automatic
> versioning for FTP writes. But, this doesn't affect the Delta-V or FTP
> protocol -- it's an implementation decision for the server.
>
> > 1.1 Do we expect all FTP servers ( and others ) to talk to the
> > versioning component?
>
> This is an implementation decision, but I'd expect most FTP/DAV server
> combos to not provide automatic versioning for FTP resources.
>
> >
> > I don't think that will be acceptable solution at all..
> >
> > If no, then:
> >
> > 1.2 how does this work? If a versioning-aware client did a
> > CHECKOUT on a file and versionig-unaware-non-HTTP client wants to
> > open the file in "read-write" mode? Will this operation fail?
>
> There are several choices here:
>
> a) do a second checkout (allow parallel development)
> b) fail the second checkout (allow only single line of development)
>
> > Whatever is the case, spec is very unclear here....
>
> We should certainly say which choice we make... (i.e., we need to fix
this
> in the spec.)
>
> - Jim
>