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

   From: CJ Holmes [mailto:cholmes@4d.com]

   >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

Received on Thursday, 28 February 2002 23:39:14 UTC