Re: Ideas: GETSRC & MULTIPUT

On Tue, Oct 30, 2001 at 01:58:36PM -0800, Jim Whitehead wrote:
>...
> There are two kinds of authoring tools: ones that are structure aware, and
> ones that are not. Structure-aware tools (i.e., a tool that understands a
> given page is comprised of N other pieces) will be programmed to know the
> relationship between sub-elements and the end-user visible Web page, and
> will have developed a naming convention that it understands. The source
> property won't provide these tools much value.
> 
> Structure unaware tools just allow the user to pick a URL and edit it. There
> is no notion of structure. Such a tool could use the source property to find
> other parts, but could still only allow a user to pick one of them to
> individually edit. A person using these tools would eventually need to
> understand the naming convention used by the parts and the whole.
> 
> Hence, I'm not convinced the source property, as currently defined, provides
> much value to any known class of client.

That is an improper conclusion. You only posed two cases, and both deal with
a resource that is comprised of many other resources. If a resource is
produced from a *single* item, then the source property is of tremendous
value. That unaware tool will take me there, and I can get my editing done.
Nothing complicated there, yet incredibly useful.

> There are really several classes here:
> 
> (a) when the mapping of resource to authorable subparts is 1::many
> (b) when the mapping of resource to authorable subparts is 1::1 (as with
> server-side includes), and the authorable rendition of the resource isn't
> returned by GET
> (c) when the mapping of resource to authorable subparts is 1::1, and the
> authorable rendition of the resource *is* returned by GET (e.g., a Word
> document)
> 
> Something like "the inverse of PUT" would be handy for case (b). WebDAV only
> provides good support for cases (c) (Office, Acrobat, drive mappers) & (a)
> (Go Live, Dreamweaver).

WebDAV also provides quite fine support for (b). I've got empirical evidence
of people doing exactly that. I've done it myself.

Don't warp your cases so that you can draw a desired conclusion :-)

The 1::many problem is hard, sure. But the existing solution provides
structure for that. Maybe you could argue some extensions, such as a
DAV:displayname for each link pair, but the concept is sound.

> > Feel free to define yet another distributed filesystem protocol within any
> > other working group of the IETF.  I'd rather wait until it gets
> > implemented correctly than reduce the standard to something that doesn't
> > meet the need.
> 
> Today, the most frequently used WebDAV client is Web Folders.  A valid way
> to view WebDAV is as a network file system protocol. While this was never my
> goal, the fact remains that the majority of WebDAV users would never notice
> if PROPPATCH, LOCK, and UNLOCK were turned off. This is changing as more
> full-featured collaborative authoring clients become available, and enter
> into widespread use. But right now, and into the forseeable future, DAV as
> Web Filesystem is an important user model.

Okay, fine. But what does that have to do with GETSRC or the source
property? Great -- so people can browse... what about it? The capabilities
offered by Web Folders are also going to be independent of the source stuff
we're discussing.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Wednesday, 31 October 2001 05:55:06 UTC