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?

       -- sandro