Re: Making MGET more GET-friendly?

> >>>>> 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.

So if a human gives a browser the URI of an RDF Property, they
get... what?  ... some documentation?

> 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.

So in general, if you're like a web browser or a search engine, or
some other thing that wants to know a lot, you do both.

I guess that makes sense.

     --sandro

Received on Friday, 12 March 2004 06:02:06 UTC