2006/5/10, Joe Gregorio <[EMAIL PROTECTED]>:
On 5/10/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> I'm not talking about client-side media-type dispatching, "the kind
> that causes so much grief", but server-side media-type dispatching.
You are going to issue GETs to the 'edit' URI, which requires
the server to choose among different representations to respond
with based on the Accept: header sent to the server.
Why?
The entry pointed to by atom:[EMAIL PROTECTED]"edit"] is the one you will
edit, so it needs to be the latest, up-to-date version. If the content
is not inlined, then the "src" attribute needs to contain URI of the
latest, up-to-date version (otherwise, the entry itself cannot verify
"latest, up-to-date"). There's no need for them to be the same URI,
but they conceptual have to identify the same resource (so one are as
"up-to-date" as the other, they share authors, and contributors,
atom:updated, atom:category, etc.)
And if you really want *two* resources, you can create another entry
with an rel="related" or rel="enclosure" link (or you can register a
new rel="about").
APP:
* atom:[EMAIL PROTECTED]"edit"] gives you the "edit URI", the URI of the
Atom Entry Document representation
* atom:content/@src in the "collection feed" can point to a "CDN"
copy while atom:content/@src at the "edit URI" points to the "always
up-to-date version"
* you PUT everything to the "edit URI", whichever representation
(part?) you want to update, and send DELETE requests to that same URI
as well
WebDAV:
* PROPFIND w/ Depth > 0 gives you the "member URI", the URI of the
resource where the default (only?) representation is the "original"
one
* If the "original" representation is not an Atom Entry, PROPFIND at
the "member URI" gives you "atom metadata" for editing with PROPPATCH
(can work too if the "original" representation *is* an Atom Entry)
* you PUT and DELETE to the "member URI"
Without conneg, the "edit URI" and the "member URI" in these two
scenarios are not the same URI, although they identify the same
*resource*. An implementation supporting both "protocols" would
support PUT and DELETE on both URIs, eventually refusing Atom Entry
Documents on the "member URI" (used for WebDAV access) if that's not
the "original" representation.
In any case, I'd say that if the client wants to retrieve (expect the
server to return) an Atom Entry Document representation, it should set
an appropriate Accept header, whichever design choice is finally made.
(corrolary: if the clients knows there is another representation and
it doesn't want the Atom Entry Document, it should set an appropriate
Accept header as well, setting application/atom+xml's qvalue to 0.0 or
a very low value)
My use case is: I'm on my blog, on an "entry" HTML page, I click the
"edit" button of my browser which opens my (fictional) "editing
client" passing it the page URI (correct me if I'm wrong but this is
how IE works). Thanks to conneg, my client is given the Atom Entry
Document rather than the HTML (which it also knows how to edit),
because it's the "original" representation.
"Media resource" use-case? well, my editing client doesn't know how to
edit images, iCalendar or vCards, etc., so it won't be given the
"picture of the beach" I'm looking at (which also has another URI,
because my browser doesn't do XHTML 2.0 and client-driven conneg: it
always send the same Accept header, including application/xhtml+xml
and text/html even when retrieving things to "show" in an <img/> tag).
In case my editing client would have known how to edit the image/jpeg,
as I know there also is an Atom Entry Document representation, I would
then have asked it to retrieve it because I actually wanted to edit
the metadata, not the data, and my editing client doesn't really know
about WebDAV.
That is content negotiation and the kind that causes problems.
I'm totally aware of problems transparent conneg can cause in remote
editing (where you edit a derived representation) but that can be
solved with good practices and good configuration: when the client
doesn't know what it wants/what the resource is (as in a "dumb" WebDAV
distributed file system), it sends no Accept header or Accept: */* and
the server sends it the "original" representation (by definition the
role of qvalues is to identify alternates' "fidelity" wrt the
"original", so the "original" should always have the highest qvalue).
Could you enlighten me about other potential problems with conneg? (it
seems I'm not the only one here needing more details)
--
Thomas Broyer
