capabilities lookup: it's the meta ...

[Ernst Johannes]

Something else had been bothering me about some of the capabilities  
lookup alternatives that we'd been discussing. I hadn't quite been  
able to put it into words, but finally, now I know what it is ... and  
I'm eager to share ;-)

FIrst, a rehash.

The operation that we are trying to define is
"given this URL, tell me what its capabilities are"

Then, an insight.

This is, if there ever was one, a "meta" traversal. Similar to
"given a Java/C#/Perl/PHP/whatever object, tell me what methods I can  
invoke on it", or
"given a URL, tell me what its properties are" (like the PROPFIND  
method in WebDAV)

Conceptually:
This is not about obtaining the resource according to a different  
surface representation.
This is also not about qualifying the GET operation of the URL with  
additional parameters.
This is a genuinely new kind of method, a "META" method, so to speak:  
we are not attempting to "GET" the resource, or "POST" or "PUT" or  
"DELETE" etc. -- instead, we are asking for its meta-data. (well, a  
particular kind of its meta-data, namely what YADIS calls its  
capabilities)

This is worth repeating: It is a GET, but not of the resource, but of  
its meta-data.

Maybe the best parallel, in a language such as Java, would be
"given this object, tell me what interfaces it supports". (please  
interpret the word "interfaces" loosely here, on the same abstraction  
level as capabilities in YADIS, I don't mean to talk about GET and  
POST etc.) as opposed to "give me an HTML or TXT or Serialized  
representation of the object" which would be an entirely different  
kind of request.

So ...
  ... the conceptually cleanest way to support this "meta" operation  
would be to add a new verb to HTTP ("GETMETA" comes to mind) -- like  
WebDAV did. In fact, there are many parallels here because a big  
chunk of what WebDAV is all about is to deal with additional meta- 
data that plain HTTP knows nothing about.
  ... but assuming we don't want to define additional verbs for the  
REST / HTTP vocabulary, which would probably be a bad idea for a  
range of other reasons
  ... assuming that you guys agree with me that "meta" is really what  
this is all about
  ... the engineering problem in front of us seems to be:

"given that we have a genuinely different kind of operation on a URL  
than people normally do these days" (side note: I very much agree  
with Mart's comment on the wiki that this capabilities/meta lookup is  
going to be much more broadly useful than "just" for identity) "how  
are we best going to use the means at our disposal to emulate this  
new operation?"

Is that an accurate description of the problem?

Note that any "meta" operation (whether in YADIS or wherever) is  
genuinely orthogonal to any parameters that specify which format the  
client wants the response to be in. Just like in plain normal use of  
HTTP, as a client I should be able to say "I like HTML better than  
PDF better than TXT" (if I'm a human) vs. "I like XML only" (if I'm a  
machine) for the meta-data of the URL, not just the resource behind  
the URL.

That's the other thing that has bothered me in the current proposals  
without being able to express it so far: we seem to have assumed that  
the capability query only makes sense for machine clients. But upon  
reflection, I don't think so: as a human, I also want to know what a  
given URL can do, and I want to know in HTML because I like it better  
than PDF better than TXT and I don't like XML. (Just as an example  
for the preferences of a human client).

Ergo, the "Accept" specification is, and must be, orthogonal to the  
"Meta" specification (in whatever form we will settle on), in order  
to be architecturally clean.

In other words, I have decided to be very much against (sorry, guys)  
using the Accept header to emulate a "Meta" operation because it  
collapses two orthogonal things onto the same dimension, and that is  
a big no-no in the architecture book that I'm following ... because  
sooner or later, we'd want to disentangle the orthogonal dimensions  
and we won't be able to if we go down that route.

Can we agree on whether this is an accurate description of the  
problem first before figuring out what that means for the protocol? I  
would have a proposal that turns out to be only a minor  
modification ... but problem description first.




Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051116/63df157c/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst