RE: GETSRC & MULTIPUT

BIND does not behave like a softlink.  BIND binds all properties from the
linked resource to the original and vice versa.  I just went to explorer,
created a shortcut to a file.  The created date on the shortcut is different
than on the original.  My point is there should be some properties that can
be different on the softlink than on the original and I do not think BIND
provides for that.  Redirect references suck because the server has to issue
a 302 and the client has to make another roundtrip.  This could be a problem
especially for low network latency and bandwidth situations.  I think there
was some other kind of reference that would do the trick (indirect reference
or something like that) but as far as getting this implemented within RFC
2518???  The link property that is part of RFC 2518 should do what I'm
talking about.  The only question is which properties are malleable between
the softlink and the original.
@m

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 1:16 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT


I'm not sure you really addressed the requirements that Jim has:

* atomic read/write of contents & properties
* getting the source file for generated content vs. getting the generated
output

The notion of symbolic links potentially has the problem where GET doesn't
return the
same stuff as PUT stored, but typically (on a filesystem), you can use
read() to get
the contents you just did a write() on, even if the pathname is a symbolic
link.

I guess I don't see symbolic links (or BINDings in the WebDAV parlance) as
relevant
to this discussion.

-----Original Message-----
From: Adam Freeman [mailto:afreeman@lightsurf.com]
Sent: Tuesday, October 30, 2001 1:03 PM
To: Eric Sedlar; WebDAV
Subject: RE: GETSRC & MULTIPUT

Hello,
1)  new methods (GETSRC, READ, WRITE) should be avoided if possible.  There
are plenty of methods in webdav already.
2)  webdav turns a website into a file system.  What does webdav seem to be
missing?  A good clean concept of a soft link.
3)  what webdav needs is something analogous to a soft link in a file
system.  The soft link resource can have a different set of properties than
the original resource.
4)  if you start from the file system concept, then you think about how
webdav should make this look transparent to the client (just like a soft
link in the file system would look but it might have a different set of
properties on it than another soft link or the original file)
5)  Using webdav currently, I could mimic this by using PUT on a .url file
(that links to the original source) and then using PROPPATCH on that .url
file.  PROPFIND then returns a different set of properties for that .url
file than the original resource but GET returns the original source bits.
This works with mod_dav.so.
@m

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
Sent: Tuesday, October 30, 2001 12:19 PM
To: WebDAV
Subject: RE: GETSRC & MULTIPUT


The fundamental question that must be addressed is whether or not the source
resource and the output resource are the same.  To me, the question boils
down to wanting to have symmetry in my methods.  If I call PROPPATCH, I can
then use PROPFIND to see the properties I just wrote.  We need the same
thing for PUT.  If I call PUT on a URL, I want a method that gets me back
the stuff I just PUT at that URL.

Even if I have a script that handles multiple resources, such as a program
called "foo.pl", that can handle

/cgi-bin/foo.pl

AND

/cgi-bin/foo.pl/werf

the argument doesn't really apply, since generally /cgi-bin/foo.pl/werf will
not respond to PUT or PROPPATCH.  It's not really a WebDAV resource.

Here's what WebDAV really needs:

* a method called READ and a method called WRITE
* The WRITE method can be used to write the dead properties and contents of
a resource in a single atomic transaction.
* The READ method can be used to read the dead properties and contents of
the resource EXACTLY as stored by the most recent PROPPATCH/PUT/ACL/WRITE
method stored them

This would address both of the needs that Jim cites.  We could also be extra
clever and perhaps add another header called Property-Length that specifies
the byte length of the property data within the message body, so that we
don't have to use multipart/mime encoding for the contents (which can be
computationally expensive).

--Eric

Received on Tuesday, 30 October 2001 17:04:52 UTC