Re: A question on Versioning-unaware clients

SOM Bandyopadhyay (SBANDYO@novell.com)
Thu, 05 Aug 1999 11:32:55 -0600 

Message-Id: <s7a9766c.050@prv-mail20.provo.novell.com>
Date: Thu, 05 Aug 1999 11:32:55 -0600
From: "SOM Bandyopadhyay" <SBANDYO@novell.com>
To: <ejw@ics.uci.edu>, <dbarrell@opentext.com>, <ietf-dav-versioning@w3.org>
Subject: RE: A question on Versioning-unaware clients


- In my email FTP was taken as an example protocol. I never asked to consider FTP within the scope of Delta-V work.

- Question was raised to consider "interoperability with existing file system protocols"....since I see some serious drawbacks if we don't consider that.
  (e.g. in one example semantics of CHECKOUT changes ).

thanks, som.

>>> Dylan Barrell <dbarrell@opentext.com> 08/05/99 01:28AM >>>
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
>