Subject: Re (2): Status of RFC2518Bis

From: [email-masked]
Date: Tue, 6 Apr 2004 22:58:44 +0200 (MEST)

Julian Reschke <[email-masked]> schrieb:
> Locking has been optional in RFC2518, so there shouldn't be any problem 
> whatsoever having a RFC2518bis-minus-locking going to draft. In fact 
> it'll be easier because locking is the area that needs most attention.
>
> That being said, what *is* your position regarding separating locking 
> into a separate document?
I wonder at the moment what we win by locking ?
Roughly speaking it's for avoiding collaborative workers to damage other peoples
work.
But it seems defining and implementing locks successfully is very difficult.
OTOH there is DeltaV which also is a means (Albeit more complex, but servers and
clients are coming) to avoid collaborative conflicts.
So who needs locking ? Me definitely not.
I would be happy to implement DeltaV and the underlying RFC2518 stuff without having
to implement locks.
So doing a RFC2518bis-minus-locking would be fine with me.
And whoever wants locks because he doesn't like DeltaV can work on a lock spec.
This also would help BIND, which wouldn't need to say anything about locks
anymore.
Locking has been a pain in the ass for years. So let's get rid of it in RFC2518bis !
This really could help us to make progress because many disagreements will
disappear.
Just my 2 cent without giving it a lot of thought.

Cheers, Edgar

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 7 Apr 2004 10:18:32 +0200

> I wonder at the moment what we win by locking ?

Well, it's certainly a much needed feature for editing in-place. Almost 
all servers
implement it, not the least because MS-Office clients use it.

Although DeltaV has much to offer in this area, there is currently a 
lack of
deltav-aware clients for general editing purposes. So, locking in WebDAV
will keep its usefullness.

As to the difficulty of implementation: the obstacles are there for new
implementors as the specification in RFC 2518 is weak. So most issues
are discovered and fixed during interop(s). There is a general consensus
among implementors how to handle them on the server side. It's
documenting this consensus that's lacking.

---

From: Jim Luther <[email-masked]>
Date: Wed, 7 Apr 2004 10:18:14 -0700

> Just my 2 cent without giving it a lot of thought.

Who needs locking? Apple's Mac OS X WebDAV file system client needs it. 
Whenever a file (a non-collection resource on the WebDAV server) is 
opened with write access, the WebDAV file system obtains a lock. The 
lock is held until the file is closed. If a WebDAV server does not 
support locks (i.e., it is not class 2 compliant), the WebDAV file 
system mounts it read-only.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Apr 2004 21:12:02 +0200

> system mounts it read-only.

Yes. Many applications need locking, and most servers provide it. 
However, it is optional right now, and will have to remain so.

So what's the best way to come up with an updated/upgraded locking spec, 
if we can't wait for RFC2518bis?

Discussion started back here: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>. 
More feedback appreciated.

Regards, Julian

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

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 7 Apr 2004 14:56:15 -0700

I guess I'd vote for Julian's option #2:

"Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore. "

--Eric

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 7 Apr 2004 14:56:22 -0700

--Eric

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 7 Apr 2004 14:56:18 -0700

--Eric

---

From: Frank Lowney <[email-masked]>
Date: Sun, 11 Apr 2004 09:41:31 -0400

Is anyone maintaining a list of WebDAV options and 'how-to' recipes from the end user perspective?  The closest thing that I can find is:

http://www.webdav.org/projects/

...where may of the links (e.g. Dreamweaver, Photoshop, Acrobat, etc.) now go to pages where WebDAV is not mentioned at all.

What I want to be able to point my audiences toward is a page that lists all or many of the things that they can do with WebDAV using applications that are likely available to them.  The items on this list should then link to pages that illustrate how one would use WebDAV with that specific application to create and maintain content.  Descriptions of how WebDAV can fit into and facilitate a work flow would also be useful.

The underlying concept is that if I want to attract content developers to the use of WebDAV, I need to be able to convince them that an investment in learning about WebDAV is likely to pay off in many areas and in many ways.

Or should I approach this as if all or most of the content creators in my audience are using either MacOS X or WinXP such that they will use these apps as if working on local files?  That is, create and save a shortcut or alias file in a convenient place. But do the current iterations of these apps really accommodate that perspective?  
-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology, 
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction more accessible.

Please note that my new e-mail address is: [email-masked]