Re: A question on Versioning-unaware clients
jamsden@us.ibm.com
Wed, 11 Aug 1999 14:42:07 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852567CA.0066E7FF.00@d54mta03.raleigh.ibm.com>
Date: Wed, 11 Aug 1999 14:42:07 -0400
Subject: RE: A question on Versioning-unaware clients
DELTA-V is intentionally not coupled to the file system as are many existing
HTTP servers. This is because there may be many different repository managers
used to persist versioned resources, and they may not be based (directly) on the
file system. WebDAV also does not attempt to provide interoperability between
other protocols and the file system. If you want to do this, a simple way is to
layer FTP on top of WebDAV using a protocol translator. You FTP client then gets
all the versioning semantics of WebDAV without having to know the protocol.
"SOM Bandyopadhyay" <SBANDYO@novell.com> on 08/04/99 07:09:44 PM
To: ejw@ics.uci.edu, ietf-dav-versioning@w3.org
cc:
Subject: RE: A question on Versioning-unaware clients
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