Re: Making MGET more GET-friendly?

On Mar 11, 2004, at 17:14, ext Sandro Hawke wrote:

>
>
>>>>> I think the extra round-trip is worth the cost,
>>>>
>>>> You'll have to back that up with some motivating arguments.
>>>
>>> It's a question of comparison of costs.   Which makes me realize
>>> there's something I don't understand about MGET: how is my software
>>> supposed to know whether to use MGET?  Is it supposed to try MGET
>>> first, see the "501 Method Not Implemented", and then fall back to
>>> GET?   So there's an extra round-trip for everything *not* served by
>>> MGET?
>>
>> You're application would simply not presume that GET is going to
>> provide a description (as opposed to a representation).
>>
>> I'm not a proponent of multiple approaches.
>>
>> I see no logic in first try this, then this, then that other thing,
>> then this other possibility...
>>
>> The whole *point* of standards is so that we can avoid such nonsense.
>>
>> One standardized methodology for accessing resource descriptions
>> (however inefficient) is better than a half dozen alternatives
>> that every client has to implement and juggle between.
>
> What would the standard say?   I have a URI, and I want to know more.
> Should I do an MGET or a GET?

That depends on who is doing the asking and what the needs are.

If it is a human, then probably a GET would be most useful, since
(a) humans tend not to care about the specifics of URI denotation
and semantics and are able to guess about alot of stuff and (b) most
humans wouldn't grok RDF/XML anyway.

If it is a sw agent, then probably an MGET would be most useful,
since (a) sw agents tend to have a hard time understanding
arbitrary web content and (b) most sw agents will probably
grok and benefit far more from the RDF/XML anyway.

Patrick


>
>        -- sandro
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Friday, 12 March 2004 05:52:04 UTC