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

I didn't understand Julian's response clearly, so I'll take another stab at
a response.

Firstly I assume the reason that you are discussing difficulty is that
you're
trying to prove that GETSRC is easier to implement/use than DAV:source.
I do agree that GETSRC is probably at least a little easier, but if we're
talking about a system where one output resource maps to one source
resource, they both are almost the same.  (If not, that needs to be
proven.)
To compare GETSRC handing a 1::1 mapping to DAV:source handing a
many:many or many::many mapping of source to output isn't a fair
comparison of GETSRC vs DAV:source.   That's more a comparison
of the complexity of supporting 1::1 vs many::1 mappings.   If it's really
DAV:source vs GETSRC that you want to compare, you only should be
looking at 1::1 mappings.

OTOH... if you're not really talking about GETSRC vs DAV:source, but
really just talking about the complexity of supporting a 1::1 mapping if
you are also supporting a many::many or many::1 mapping, then I think that
comparison is more appropriate, but I also think that we haven't clearly
defined
a protocol that supports many::many yet.  As we've pointed out, DAV:source
really isn't clearly defined.  We don't know what kind of flexibility it
will be defined
to support so we don't know what kind of burden it creates.  Until it's
defined, we
can't really envision what it's like to support a many::many mapping.  I
hope
we rapidly define how DAV:source supports composition from many underlying
resources.  Then we do the comparison.

Anyway... what I say below assumes you're talking about comparing GETSRC
vs DAV:source on a server that just supports 1::1 mappings.   If this is
not
your scenario,  please forgive me.


> >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.
But in your case of GETSRC you have to do the same thing.  If it's
hard for one, it's hard for the other.    Just because a server
supports DAV:source doesn't mean that it's going to put it's
data in weird hard-to-find places.  It's very likely to put
everything physically in the same place a pure GETSRC server
would.


<<
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.
>>
Having the JSP be DAV-aware is of course a terrible burden, but I
don't think anyone is suggesting it needs to be.  The mapping would
not be done at the JSP layer.  And even if it would be, it would
be the same mapping that one would use for a pure GETSRC server.


<<
In the more common case where "GET x" is dynamically generated from
some source at the same URI, then there's hardly anything to be done
at all to support GETSRC.  All of the same machinery that normally
locates a file works just like it did before, which is the beauty of
it.
>>
That sounds great.  But the same would almost certainly be true for
a server that supports DAV:source.  It doesn't have to be true for
such a server, but it doesn't have to be true for a pure GETSRC
server either.  But it seems reasonable to keep the underlying
resource where you've described so both implementations are likely
to do it that way.


<<
The only differences are:


             1. The security module checks to make sure that the user has
permission to "GETSRC x".  In Apache, this is just a matter of adding
GETSRC to the list of methods a user is allowed to use within a given
realm.

             2. The PHP/JSP/Whatever plug-in doesn't try to pick up the
request, because it doesn't know what to do with a GETSRC method.
(Just like it doesn't try to claim anything with PROPFIND or DELETE
methods.)  In fact, all plug-ins that work only with GET, HEAD, and
POST methods just ignore the request entirely, which is what you want
for serving "source" data.

             3. Either the DAV module can claim the request, or the
mechanism that serves static files can serve the request.  In our
case (WebSTAR) we would probably just let the "default" plug-in do
it, since that module normally serves static content without
interpretation and it supports byte ranges, which is handy.  There's
no point in duplicating that code in the DAV plug-in.
>>
I think these three points are more to the point.  This sounds pretty
easy and that was half your point.  The other half of your point is that
it's hard to support DAV:source.  I think a supporter of DAV:source would
say that they'd just install a filter in Apache for URL's with a magical
something in them that distinguishes them and would handle all method calls
to those resources. If you want to prove that
doing DAV:source is much harder than doing GETSRC, someone still needs to
show that doing DAV:source is hard.  My intuition tells me it isn't
as easy as GETSRC, but that it probably couldn't be described as hard.

Again, this is all only for a server that is only supporting 1::1 mappings.
Any other type of server isn't clearly defined yet.


FWIW... I don't think anyone so far has proposed that a server support
GETSRC without supporting DAV:source, so pointing out that GETSRC is
easier for a server to implement than DAV:source is a moot point
because in the current proposals the servers would implement DAV:source
anyway and implementing GETSRC would be an optional extra effort (only?)
to offer clients a way to access the source of a resource in single HTTP
request rather than having to do a PROPFIND first.

Anyway, see my comments at the top of this posting.  They might make much
of this moot.

J.

Received on Friday, 1 March 2002 11:04:38 UTC