The reliance on Content-type

[Ernst Johannes]

On Nov 14, 2005, at 12:45, David Recordon wrote:

> The issue with any of the URL based magic is that it doesn't work  
> along
> with the concept of owning a single URL.

I agree with the statement, but I'm not certain any more that this is  
a principle that overrides everything else. (as much as I like  
REST, ...)

For example, the case has been made that it is much simpler for Joe  
User to upload an additional file to his website than it is to change  
his HTML head entry or the script that runs at that URL. Based on gut  
feel, this sounds right.

> When I say I am http://daveman692.livejournal.com it means solely I  
> own
> that one URL, not that I own the directory under it, the directory
> itself, a directory above it, etc.  You very well could have
> http://www.example.com/david.html and
> http://www.example.com/johannes.html.  The URL magic, as proposed,  
> would
> not fit this use case.

I tried to cover this with Draft-002-c-1 vs. Draft-002-c-2
on http://yadis.org/wiki/Draft-002

Come to think of it, there's another alternative: append but without  
the suffixes.

> The issue I see is a tradeoff between a ?meta=capabilities request or
> using the HTTP accept header.  Both have their own advantages and
> disadvantages and provide their own adoption issues.  Could we tackle
> both with the following?
>
> GET / HTTP/1.1
> Host: www.example.com/david.php?meta=capabilities
> Accept: application/xrid+xml, text/html;q=0.5

Hmm, does this add the advantages and subtract the disadvantages, or  
does it subtract the advantages and add the disadvantages? ;-)

I still think the HTTP header trick subverts the goal of HTTP content  
negotiation, and while it's really cool, I have no idea what kind of  
trouble it could get us into in the longer term.

Just to be clear: I don't think there's a perfect choice here and I'm  
not arguing any of them is.

BTW, do you agree with the pros and cons as I have them on on http:// 
yadis.org/wiki/Draft-002 ?

> So the YADIS spec would say it should do the request with both the
> accept header and the CGI style variable?  No overhead on the consumer
> side and then the server's implementation gets to choose which is  
> easier
> for it to support.  Seems to address the adoption issues we see from
> either side, unless there is still something I'm missing.
>
> --David

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/20051114/0b7a532d/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst