Re: Making MGET more GET-friendly?

On Mar 10, 2004, at 11:18, ext Dirk-Willem van Gulik wrote:

> On Mar 10, 2004, at 9:52 AM, David Powell wrote:
>>>> How about if it was MANDATORY for responses to MGET to have a
>>> s/MGET/GET/ perhaps ?
>> No, I meant MGET here. I was proposing that you could continue to get
> Ok - so you still need some code in the agents.

No more so than for GET, POST, PUT, DELETE, etc. etc.

URIQA does not increase implementational burden on the client side.

>> the resource using GET , and that you could
>> get the resources metadata using MGET , but
>> that the MGET would also return a Content-Location header pointing to
>> or
>> which could then be used by GET requests for agents that didn't
>> support MGET. This would help MGET data to still be part of the wider
>> web.
> ....
>> This still assumes a 1:1 relationship between data and metadata, but
>> it makes getting metadata, and getting remain separate operations
>> which could have independent access controls.
> If you assume that - and given the above 1:1; would it not be simpler 
> to simply
> postulate an extra header:
> 	Characteristics-Location:
> in the reply of any GET ? In particular that of the GET of 
> And making sure you -also- get it when a cheaper HEAD is done ? Or 
> does that
> not accomplish all you want ?

No. It doesn't (for me). Please see the URIQA FAQ about the shortcomings
of the header approach...



Patrick Stickler
Nokia, Finland

Received on Wednesday, 10 March 2004 05:13:46 UTC