capabilities lookup: it's the meta ...

[Ernst Johannes]

I'm not actually attempting to propose a new HTTP method -- only to  
get agreement that this would be the cleanest conceptual solution.

Because if we agree on that, then the only question that remains is  
"given that we won't do a new HTTP method any century from now, how  
can we best create a workaround that behaves just like it".

The purpose of my message was to get people -- like yourself and Dan  
Libby earlier -- to say "this sounds right" so we can agree on that  
basic point. Then the discussion becomes much simpler because we know  
what we want to accomplish conceptually -- such as orthogonality  
between particular features -- instead of getting lost in the hairy  
details of q=0.5 or whatever.


On Nov 16, 2005, at 11:20, Grant Monroe wrote:

> I think that this is definitely on the right track conceptually, but
> creating a new HTTP method sounds a bit impractical. I'm not even sure
> if you can get Apache to accept a request for an unrecognized http
> method. Also from a consumer implementation standpoint, this would
> complicate things. For example, python's urllib2 could not be used for
> fetching because it is only designed to work with HTTP. I'm also not
> sure how web proxies would handle requests for a different method.
>
> Grant Monroe
>
> On 11/16/05, Ernst Johannes <jernst+lists.danga.com at netmesh.us> wrote:
>> 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
>>
>>
>>   http://netmesh.info/jernst
>>
>>
>>
>>
>>
>>
>>

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/5f31552d/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst