Re: RULE vs MGET

Hi Patrick,

Apologies - I didn't read the faq on the URIQA page. It says:

Why not have a standardized suffix, prefix, or other URI
transformation that allows one to derive from a resource URI another
URI via which the resource description can be accessed?

    Such an approach both violates the sanctity of the web authority's
    URI space, since an agent has no way of knowing whether the web
    authority subscribes to such a transformation. It also violates
    the principle of URI opacity. Finally, such a transformation would
    have to work with any URI scheme whatsoever, which may very well
    not be feasible.

But I'm not convinced yet:

You could say the same about the MGET http method - the agent has no
way of knowing whether the server has implemented it in the way it
expects. MGET could quite easily mean 'multiple-get' or something.

By violating the sanctity of the web authority's URI space, do you
just mean that the web authority isn't free to use that uri to
represent something else? 
Is this likely to be a real-world issue? - the transformation could be
particularly verbose.

I also don't understand the last bit - why would it have to work with
any URI scheme? Can it not just be defined to work with HTTP?

RULE still sounds like a good bet to me - the agent wants to get a
representation containing the description of http://example.com/foo,
so it tries a GET on http://example.com/foo.meta. If the response
comes back with some metadata describing http://example.com/foo then
bingo!

Cheers,

Phil


Phil Dawes writes:
 > 
 > Hi Patrick,
 > 
 > What are the advantages of MGET over the RULE technique (e.g. add
 > '.meta' onto the end of the URI) for getting metadata about the
 > resource. I don't think I've heard any arguments to persuade me that
 > this isn't a workable solution. (other than it's a bit ugly).
 > 
 > Advantages of RULE over MGET:
 > 
 >  - no change required to web infrastructure (proxies, caches, webservers)
 >  - no change required to http client libraries (even the broken ones!)
 >  - simple to deploy 
 >         - e.g. can be done by putting text files in an existing
 >         public_html dir
 > 
 > These seem pretty big advantages to me.
 > 
 > Many thanks,
 > 
 > Phil
 > 
 > 
 > 

--

Received on Wednesday, 10 March 2004 05:35:04 UTC