content negotiation and cosmo

On Mar 13, 2006, at 3:31 PM, Matthew Eernisse wrote:

> Content negotiation does on its face seem to be more
complicated,  
> and a
> bit more opaque and brittle than the simplicity of
allowing explicit
> choice of content-type through the URI.
>
> The one bit of personal experience I have with this
type of thing  
> is the
> responseXML property of the XHR object not getting
populated properly
> because the response from a Web service comes back with
a MIME type of
> 'application/soap+xml' instead of the expected
'application/xml' or
> 'text/xml.' A lot of people seem to get bitten by
this because the
> response coming back is clearly well-formed XML, and
the only way to
> figure out what's wrong is to know that XHR is broken
in this way and
> inspect the headers of the response.
>
> My two piastres.
>
>

The main issue I have with content negotiation is that it
requires  
that clients that use it know the right stuff to put in
Accept. What  
if you have some client which wants an Atom feed, but the
only way to  
get an Atom feed is to use a URL like "http://cosmoserver/home
/user/ 
feeds" in conjunction with the proper Accept header.
If your client  
doesn't know from Accept hearers and you have no way to
tell it to  
use them then you are out of luck.

Whereas the URI based way you can do:
	http://cosmose
rver/home/user/feeds/rss
	http://cosmos
erver/home/user/feeds/atom
	ht
tp://cosmoserver/home/user/feeds/someotherformat

and know just what you're getting.

I guess it's similar to the problem the author describes
where he  
says "I get no chance to tweak the services Accept:
header."

Maybe you could have your cake and eat it too like this:

	When doing a GET in the user's DAV home without an Accept
header,  
(they're not required, right?) return the default cosmo
format for  
that resource. If they specify something in Accept, respect
the  
client's wishes.

	In addition, have content-type-specific paths for different
feeds  
and formats, and requests in those paths will only return
the one  
type of format that it is intended for.

This way you get maximum interop:

	1) For clients that are don't use "Accept" but
have users who know  
which URI to use it works.
	2) For clients that DO use "Accept" but have
users who don't  
understand the difference between the different formats and
hence not  
know which path to put in (or don't want to think about it)
it also  
works.

Bobby

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 3/14/06, Bobby Rullo <brosafoundation.org>
wrote:

> Maybe you could have your cake and eat it too like
this:
>
>         When doing a GET in the user's DAV home
without an Accept header,
> (they're not required, right?) return the default
cosmo format for
> that resource. If they specify something in Accept,
respect the
> client's wishes.
>
>         In addition, have content-type-specific paths
for different feeds
> and formats, and requests in those paths will only
return the one
> type of format that it is intended for.

yeah, it is probably not a problem to forward the request to
the feed
url if we see the Accept header asking for atom instead of
the default
format. again, there is the question of whether there are
different
security requirements for the atom url - but if there are,
then we can
always send an external redirect rather than internally
forwarding.
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

I have trouble imagining a situation where one format would
have  
different security requirements than another unless
publishing in one  
format taxes the server in some way - like uses up tons of
bandwidth  
or CPU.

Like (this example stretches it) if you had a music server
and asked  
for the original WAV instead of an mp3 which would use too
much  
bandwidth.

On Mar 14, 2006, at 7:29 PM, Brian Moseley wrote:
>
> yeah, it is probably not a problem to forward the
request to the feed
> url if we see the Accept header asking for atom instead
of the default
> format. again, there is the question of whether there
are different
> security requirements for the atom url - but if there
are, then we can
> always send an external redirect rather than internally
forwarding.
> _______________________________________________
> Cosmo mailing list
> Cosmoosafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo