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

Actually, the issue is not a 1-1 mapping, since GETSRC can handle a many to
1 mapping (many output resources for one source).  It just doesn't handle
the case of multiple sources for one output resource.

--Eric

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, March 01, 2002 8:49 AM
> To: w3c-dist-auth@w3c.org
> Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
> Just to keep this thread focused, Jason's assumption is correct that we
> are all just talking about the comparitive difficulty/benefit of using
> DAV:source vs. GETSRC (or Translate) in the case where there is a 1-1
> mapping.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Friday, March 01, 2002 10:57 AM
> To: CJ Holmes
> Cc: Clemm, Geoff; w3c-dist-auth@w3c.org
> Subject: 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 Monday, 4 March 2002 15:05:46 UTC