Re: RULE vs MGET

On Mar 10, 2004, at 12:33, ext Phil Dawes wrote:

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

That's true. But then, a server might just as well implement GET
in some proprietary way. There's no garuntee that just because a
server responds to an HTTP request that it will "do the right thing".
This is not specific to URIQA.

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

Exactly.

> Is this likely to be a real-world issue? - the transformation could be
> particularly verbose.

Doesn't matter. It's a very important architectural principle. How
are we to know what might or might not be problemmatic for some
web authority. The whole point of having a generic architecture
which draws lines around such distinctions is so that we can
build applications without having to worry about potential
collisions, however rare or unlikely.

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

There are more URI schemes than just 'http:' which are meaningful
to HTTP, and who can know what useful, even essential URI schemes
might arise in the future. Again, sound architecture helps us
have more future proof, portable, and robust applications.

Just because you can't point your finger today at a particular problem
arising from violating a key architectural principle does not mean
that tomorrow you might not run out of fingers to point at all the
problems -- and often, problems beget more problems. Best not to
cross that line at all.

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

The RULE approach, unfortunately, amounts to something of a hack, and
has numerous shortcomings relating scalability, modularity, opacity,
and long-term robustness.

While URIQA may be a hard sell, I think RULE would be far harder.

Cheers,

Patrick

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

--

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

Received on Wednesday, 10 March 2004 05:44:55 UTC