Subject: RE: Proposal: WebDAV and transactions

From: "Babich, Alan" <[email-masked]>
Date: Mon, 2 Sep 2002 13:59:12 -0700

One thing you do NOT want under any circumstances are 
begin-transaction, end-transaction, and abort-transaction 
methods. That approach simply does not scale beyond a single
user, and is a performance disaster.

You absolutely need to stick to single method calls that can 
Perform Multiple operations on the server in a single 
Transaction. Batching up operations is a valid approach.

Transactions aren't that easy to deal with. That becomes
Even more true when multiple servers are involved. Someday,
WebDAV might get that far.

Transactions aren't new. They're decades old. The effort would
Profit from the decades of thought that has gone before.
For example, see the DMA standard for one approach. (But
remember: DMA specifies an API, not a protocol, and WebDAV is a 
protocol.)

Dr. Alan F. Babich

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 4 Sep 2002 15:01:51 +0200

Hi,

one thing that the participants of the interop meeting may want to
consider...

A long time ago ([1]), Microsoft proposed a live property DAV:ishidden which
signals that a resource should be displayed as hidden in a UI.

Support currently exists in:

MS IIS 5.0: reports DAV:ishidden according to the file system flags of the
underlying file system
MS webfolder client: asks for DAV:ishidden, and hides the resource when it
is reported as hidden
SAP Enterprise Portal Server: treats DAV:ishidden as live property with the
semantics defined in [1]

I think this is a really useful feature, and in case we can identify another
client that supports it, we may want to roll it into RFC2518.

Regards, Julian

[1] <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props-00.txt>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Jim Luther <[email-masked]>
Date: Wed, 4 Sep 2002 10:18:42 -0700

If this were part of the standard, I'd certainly want to support it.  
Mac OS X creates some files which are intended to be hidden (being UNIX  
based, Mac OS X hides files which begin with a "." character) and so a  
standard WebDAV property to indicate that a file is supposed to be  
hidden would be welcome.

- Jim

On Wednesday, September 4, 2002, at 06:01 AM, Julian Reschke wrote:

> [1]  
> <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props- 
> 00.txt>
>
> --

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 4 Sep 2002 11:29:21 -0700

Are any other of the Microsoft proposed extensions of general interest?
They have a property like "has-children" or something as well, I believe,
that they use...

--Eric

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 4 Sep 2002 19:07:40 -0700

One property that keeps coming up (also in the Microsoft proposal) is the
resource-ID property, to uniquely identify a resource (generally a GUID).
I'm constantly getting requests from internal groups for this, and I know a
lot of the JSR-170 people are interested in this for content management
apps.

Of course another related requirement is the ability to fetch resources by
ID.  This could be done either by fully utilizing the DAV: namespace, e.g.
DAV:<resourceID> as the URL or by waiting for DASL.

--Eric

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 5 Sep 2002 10:17:26 +0200

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 4:08 AM
> To: [email-masked]

As Geoff pointed out, this will be available as part of the BIND spec. It
could be used on systems even when they don't specifically support the BIND
method.

> DAV:<resourceID> as the URL or by waiting for DASL.

First of all, the "unique resource ID" just is a URI. Which URI scheme is
used is up to the server. So it's completely free to assign an HTTP URI, and
this obviously could then be used to fetch the ressource. If the resourceId
isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.

Re: locating a WebDAV ressource by resourceid -- this won't work with the
current DASL spec (at least not with the DAV:basicsearch grammar), as I
expect the property to have DAV:href content -- something in which you can't
search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
appropriate...

Julian

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 5 Sep 2002 11:12:28 -0700

> search using DASL. Therefore, a REPORT (locate-by-resourceid) may be

What is needed is an interoperable way, given a resource ID, to operate on a
resource with that ID on the server.  If the mapping between resource-ID and
implementation is server-defined, we can't do that.  Requiring the DAV:
namespace to respond to these requests is probably the easiest thing to do,
since this will work with other methods, like LOCK and so forth.  REPORT
doesn't handle that case.

--Eric

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 5 Sep 2002 20:32:23 +0200

> Sent: Thursday, September 05, 2002 8:12 PM
> To: Julian Reschke; [email-masked]
> ..

Eric,

WebDAV is an HTTP extension. There's simply no way to directly manipulate a
resource identified by a DAV: URI using HTTP/WebDAV. Is this *really* what
you're proposing, or am I missing something?

Julian

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 5 Sep 2002 11:35:18 -0700

didn't think about that problem...

What I'd like to be able to do is to have a URL-based scheme for accessing
resources by resource ID, without having to run a REPORT or SEARCH method or
something to find a URL for it, especially since that will be yet another
spec.

OK, how about if we make resource IDs <href>s that are guaranteed to be
unique?  We had to do the same thing with principals in the ACL spec to
uniquely identify them.  So, rather than treating resource ID as an opaque
string, we can do something with it.  On a server storing GUIDs for each
resource, you could return:

http://myserver/sys/ids/<GUID>

as the string rather than just

GUID

--Eric

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Eric Sedlar" <[email-masked]>; "Julian Reschke"
<[email-masked]>; <[email-masked]>
Sent: Thursday, September 05, 2002 11:32 AM
Subject: RE: Interoperability for DAV:ishidden?