RE: A case for GETSRC (or other mechanism to that effect)

The problem with having multiple ways of doing things
is that it harms interoperability, when one server does one thing
(maintain the DAV:src property) and another server does another
(a GETSRC method or a Translate header).  Servers are always going
to have proprietary extensions, and widely distributed servers
(e.g. IIS) are going to have clients coded against those proprietary
extensions, but the goal of the standard protocol is to produce an
interoperable protocol, which means not providing different alternative
ways to produce the same result.

Cheers,
Geoff  

-----Original Message-----
From: CJ Holmes [mailto:cholmes@4d.com]
Sent: Friday, March 01, 2002 1:04 PM
To: w3c-dist-auth@w3c.org
Subject: RE: A case for GETSRC (or other mechanism to that effect)


>    From: CJ Holmes [mailto:cholmes@4d.com]
>
>    Well, you can't always "just locate the source".  If the source
>    really is in a different location than the "normal" URI then your
>    DAV module probably has no knowledge of it.  Which means now you
>    have to teach JSP to be DAV-aware and answer PROPFIND requests, or
>    teach your DAV module all about what URIs are served by which other
>    modules and how the two URI spaces map to each other.

>
>My primary objection to GETSRC is that it represents a non-extensible
>direction to follow.  For example, one of the key purposes
>of PROPFIND was to provide semantic indexing of web resources, and the
>indexing of the display information should be significantly different
>from the indexing of the source information.  Once you have taught the
>DAV module to understand the difference between display URL spaces and
>source URL spaces, it can produce this kind of indexing.  Similarly,
>any other kind of method that could sensibly be applied to both the
>display and authoring resources can take advantage of the separation
>of display and authoring into separate identifiable URLs.

I agree with all of this!  I have no bones whatsoever to pick about 
the superiority of keeping source and display resources separate, or 
its happy consequences.  For an integrated content management system 
you would definitely want this, and it would be pretty darn cool.

What I disagree with is the _requirement_ to keep the two spaces 
separate, which burdens administrators with a lot of extra 
configuration, isn't understood by most content-generation software 
today (if any), and often confuses the end-users who can barely use 
Dreamweaver/Golive/FrontPage much less understand why their "browser" 
URL is different from their "Dreamweaver" URL.  For most 
installations, keeping the URIs the same is a desireable thing and 
does not cause anyone to lose any functionality that they care about. 
Most people don't care about indexing their source, and we have 
specialized crawlers already for indexing display content.

I'm just saying that the simple things should be easy.  It's a basic 
rule of design.

I'm not stuck on the GETSRC idea. I'll implement Translate almost as 
happily if that's the direction the group goes.  If the group doesn't 
come up with anything at all, then Translate is likely to become the 
de-facto standard, and you'll end up putting it into RFC-2518-bis2 
anyway.

cjh

--

Received on Friday, 1 March 2002 13:37:26 UTC