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

From: CJ Holmes <[email-masked]>
Date: Fri, 1 Mar 2002 10:03:37 -0800

>    From: CJ Holmes [mailto:[email-masked]]
>
>    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

--

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 2 Mar 2002 01:46:53 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of CJ Holmes
> Sent: Friday, March 01, 2002 7:04 PM
> To: [email-masked]
> Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>

There *is no* requirement to keep the spaces separate, just the individual
URIs. For instance, for any given ASP resource "x" you could generate a
DAV:source pointing to "x.~source~", and the serve the source code (and
accept PUTs on the source code) on that URI.

> URL is different from their "Dreamweaver" URL.  For most

That's why the DAV:source property was defined. It enables clients to
automatically discover the source URIs (and to offer to edit *them*
instead).

> specialized crawlers already for indexing display content.

Sorry, but if we can't agree on the simple axiom that different resources
need different URIs, there's really not much point debating.

Again: do you consider the source and the output to be the same resource?

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

Yes, but it can be only as simple as reasonable possible.

> happily if that's the direction the group goes.  If the group doesn't

That's just a little syntactic difference. Both share the same problems.

> de-facto standard, and you'll end up putting it into RFC-2518-bis2

Translate already *is* a de-facto standard, but that doesn't mean it
automatically qualifies as acceptable solution.