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

From: "Jason Crawford" <[email-masked]>
Date: Thu, 28 Feb 2002 09:54:36 -0500

I am in favor of DAV:source and agree it needs work and can accept it going
in a seperate spec.  This need not be to the exclusion of another option.

My priority is in getting 2518 updated, but I'd be eager to take part in
the discussion of DAV:source and it's alternatives.  I think it's an
important issue.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Thu, 28 Feb 2002 09:24:53 -0800

I think a fundamental web architecture issue is being
ignored if we simply look at URL space as a functional
categorization. IMHO, it should be viewed
as a means for classification (as originally intended)
of information, and thus humans should be able to find
resources given an information architecture.  If we assume
a separate/distinct namespace is a requirement, we throw away
the ability to maintain a valuable abstraction.  There
is precedence in presentation of information given
context (.e.g., role) and making DAV:source work would
satisfy this.

Phillip A. Lindsay ([email-masked])
Principal Architect
Day Software, Inc.

                    "Clemm, Geoff"                                                                                                               
                    <[email-masked]       To:     [email-masked]                                                                       
                    om>                      cc:                                                                                                 
                    Sent by:                 Subject:     RE: A case for GETSRC (or other mechanism to that effect)                              
                    w3c-dist-auth-requ                                                                                                           
                    [email-masked]                                                                                                                   

                    02/28/2002 06:04                                                                                                             
                    AM                                                                                                                           

As I recall, I was willing to consider the Translate header
or a GETSRC method, if I was the only one who found them
objectionable.  I consider a separate URL space for authoring
a superior approach, since I believe separate URL spaces
are a simpler model, and one that will prove to be more
extensible.  It also is very compatible with common web server
extension mechanisms, which allow you to dispatch to different
modules based on what part of the URL space you are operating in.

So with support from Julian, it no longer is "just me", so I
revert to my natural position, which is against both the
Translate header or a GETSRC method.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 6:12 AM
To: [email-masked]
Subject: RE: A case for GETSRC (or other mechanism to that effect)

>From: [email-masked] [mailto:[email-masked]]On
Behalf Of Eric Sedlar
>Sent: Thursday, February 28, 2002 10:43 AM
>To: Peter Raymond; Julian Reschke; [email-masked]
>Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
>Comments inlined...

To all: please do not post in HTML. It makes commenting hard, and it breaks
the web archive.

>The proposal would be that Translate: F would only have an effect on the
GET method, and could be either ignored or forbidden on other methods ( one
of the nits that Geoff picked at >at the dinner where we won him over)...

I see. I guess he dind't have to pay his bill either :-)

>There is certainly interoperability for Translate: F, so I don't see why
that needs to go into a separate spec.

It's not defined in RFC2518, so it can't easily be put into it's revision.
If you want to put it in, you'll have to get agreement on lots of issues
(some of which we already discussed). As there currently is *no* technical
documentation about the Translate header, it will be hard to get proper
definitions of it's semantics (saying: "whatever Frontpage does" doesn't
count).

>>- I am also interested in managing more than just websites and may need a
more advanced way of
>>  navigating relationships (perhaps between design documents and the code
that implements them or
>>  between firmware and circuit board designs etc).  This can best be
addressed in another specification.
>The issue of how the executable is generated is a separate question from
getting at the executable content itself (see my reply to Julian's email).
>Regards,

I think you currently consider only a few special use cases. DAV:source was
designed to address a more generic problem. I think it can be fixed, and we
should try this.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 28 Feb 2002 12:33:32 -0500

A counter argument is that the URL space is demonstrably a
very poor mechanism for searching and classifying information,
thus the introduction of search engines, and protocols like
WebDAV that introduce "properties" that allow you to declare
the information needed for content and keyword based searches
and classification.  That is one of the reasons why
it is preferable for the "source" and the "result" be distinct
resources (with distinct URL's), so that the property mechanism
can be used to locate either the source or the result, depending
on what you are interested in.

Cheers,
Geoff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 12:25 PM
To: Clemm, Geoff
Cc: [email-masked]; [email-masked]
Subject: RE: A case for GETSRC (or other mechanism to that effect)

 

                    "Clemm, Geoff"

                    om>                      cc:

                    Sent by:                 Subject:     RE: A case for
GETSRC (or other mechanism to that effect)                              
                    w3c-dist-auth-requ

                    [email-masked]

                    02/28/2002 06:04

                    AM

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 6:12 AM
To: [email-masked]
Subject: RE: A case for GETSRC (or other mechanism to that effect)

Behalf Of Eric Sedlar

more advanced way of
that implements them or

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 28 Feb 2002 17:10:11 -0500

I agree with Julian's question, i.e. why don't you just use
some natural URL to expose your editable source.  In general, the
file extension of the actual file containing your editable source
will not be ".html".  It will be .asp, .jsp, or whatever.  So the
natural URL for the jsp source for /x/y/foo.html is /x/y/foo.jsp.
Why not just use that URI to identify your source resource?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 3:38 PM
To: CJ Holmes; [email-masked]
Subject: RE: A case for GETSRC (or other mechanism to that effect)

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of CJ Holmes
> Sent: Thursday, February 28, 2002 8:33 PM
> To: [email-masked]
> >  > The only time Translate/GETSRC is relevant is for executables (cgi's,
> >>  servlets, etc.) at a particular URL which generate some
> dynamic content.
> >
> >I don't agree. DAV:source may be relevant for "compiled"
> resources as well.
> >For instance, static HTML might be generated by a one-time compilation
> >process, but you don't want anybody to *modify* the HTML. Rather, people
> >would need to be pointed to the modifiable source (for instance, XML and
> >XSLT input files).
>
>
> Agreed.  I am not arguing against DAV:source at all.  I think it is a
> good idea, and I recognize its architectural superiority.
>
> What I object to is that the current model makes simple things very
> hard to implement and a hassle to manage for no real gain to most
> people.

I think you need to prove that if you want to introduce a second model for
something that could be solved using DAV:source.

> >  > So, there are really three different sets of content we are
> looking at:
> >>
> >>    1)  the generated output returned by GET
> >>
> >>    2)  the executable that generates the content for GET, and
> which is the
> >>  object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK,
> >>  MOVE, COPY,
> >  > ...)
> >  >   3)  the multiple source files that were used to generate
> the executable
> >>
> >>
> >>  The GET method returns resource #1, dav:source (if it were actually
> >>  implemented by anyone) would list #3.  Translate: F, or
> GETSRC, returns
> >>  resource #2, which is the one logically consistent with the
> other WebDAV
> >>  methods.
> >
> >Yes, but dav:source can do this for you as well. Why have two different
> >models if one is enough?
>
> Nobody is suggesting two models.  I'm suggesting a change in the
> current model.  Instead of GETSRC, let's call it DAVGET just to
> relieve us of some preconceptions.
>
> 	GET is undefined by DAV
> 	PUT and DAVGET are symmetric
> 	Properties belong the result of DAVGET
> 	If URI "x" is compiled from sources at other URIs, then:
> 		DAVGET "x" will retrieve the resource
> 		PROPFIND "x" will retrieve the properties of DAVGET "x"
> 		GET "x" would probably return the same resource as
> DAVGET "x" (impl dependent)
> 		PUT "x" will result in an error (impl. dependent),
> since the sources lie elsewhere.
> 		PUT to the source URI(s) of "x" will affect the
> properties and value of DAVGET "x"

Having a new GET method that returns completely different resources than
GET, and defining that PROPFIND operates on DAVGET rather than GET is not
only a new model, it would change WebDAV at it's core. Why do this if this
isn't needed????

> You can still have DAV:source and it will be just as useful as it is
> now.  But the common problem of how people use DAV to edit their
> source files is resolved.

It can *easily* be solved using DAV:source.

> >  > Real-world experience has shown that:
> >>
> >>  * nobody actually tracks multiple source files for an executable
> >>  * people sometimes want to actually get the executable contents
> >>
> >>  Nobody has actually come up with a real-world use-case for
> dav:source, but
> >>  whether or not dav:source is deprecated or not, it's actually
> >>  identifying a
> >>  different set of content than Translate: F / GETSRC.
> >
> >I disagree. Could you please explain why the model used in
> DAV:source can't
> >be applied to this use case?
>
> It can, but it just isn't worth the trouble.  It is a LOT of extra
> work for absolutely no gain.  You gain nothing from DAV:source that
> you don't get for 1/20th the work from Translate.

That's a broad claim. Can you prove it?

> If I were to spend a programmer month implementing DAV:source,

Why would that take so long?

> administrators would still have to set aside special URL spaces and
> turn off all plug-ins for that space and add a lot of new security

No, they don't.

Nobody says that they *have* to set aside a special URL space.

For instance, for any "output" resource "x", you could have a source
resource "x" + ".~~~~~source~~~~~" which represents the editable source code
of this resource. No separate URL space.

> realms, just like they do now.  We could implement it, but in terms
> of managing the server we're left with the same mess that already
> afflicts our users.  There's just no point in implementing DAV:source
> unless you have some kind of tightly-integrated document
> management/compilation system that tracks multiple sources for the
> GET results of dynamic URI(s).

The only difference is that you might have more than one source. It escapes
me why the special case of having just one source justifies breaking basic
Web axioms by having different resources with the same URI.

> And so we're left in a situations where the simplest task is
> quite difficult.

No, it's not.

Maybe you could step back and describe why you think it's so much more work
generating a second URI for the editable source resource.

> >Actually, having a one-to-one mapping of executables to their output (for
> >instance foo.asp) is a very bad practice. Everytime you change your
> >underlying implementation, URIs will change. However, cool URIs don't
> >change.
>
> Nobody is trying to tie down executables to output on a one-to-one
> basis.  Nobody is trying to get rid of DAV:source.  We're just trying
> to adjust the current model to make the simple things easy, while
> maintaining support for the the difficult (and architecturally more
> interesting) things.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 28 Feb 2002 23:38:41 -0500

From: CJ Holmes [mailto:[email-masked]]

   >Why is it easier to get the server to implement GETSRC
   >(which requires it both to locate, and then retrieve the
   >contents of the source) than it is to get the server
   >to implement PROPFIND <DAV:source>, where it just has to
   >locate the source, and return its URL?

   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.

I agree that in some implementations, it will take more work to teach
the DAV module about how to map a display URI space to an authoring
URI space.

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.

So although possibly more work in the short run, I believe the work
put into supporting a separate URL space is the direction that the
protocol should be encouraging server vendors to pursue.

Cheers,
Geoff