On 10/15/05, Tim Bray <[EMAIL PROTECTED]> wrote: > > On Oct 15, 2005, at 4:32 PM, Robert Sayre wrote: > > >> I am definitely in favor of accomplishing this using something within > >> the entry that you PUT rather than extraneously via a header, because > >> it means that the message is more completely self-describing. > > > > In HTTP, the message is composed of the headers and the body. See > > section 4.2 and 4.3 of RFC2616. For example, the request line is part > > of the message. > > Restating: I am definitely in favor of accomplishing this using > something within the content of the <atom:entry> that you PUT, > because (a) I can look at the XML and know what's going on and (b) I > might want to ship self-contained updates around on non-HTTP channels.
I find (a) to be false. When I am debugging HTTP traffic, I paste the URI into my browser and watch things go by in the Mozilla LiveHTTPHeaders extension. They are name/value pairs and are easy to read. I have spotted bugs in my own and everybody else's APP implementations this way. If I can't figure out what's happening, I fire up httpflow.py or Ethereal. If I still can't figure out what's happening, I dive into the message bodies and get a little grouchy. I think (b) is not a goal for this WG. I am not opposed to shipping Atom around on other protocols--I have written code to send Atom over SOAP, XMPP, and BEEP. I think the current design is inside-out SOAP: <soap:body><soap:headers></soap:headers></soap:body> I have never need such an envelope. If you have special stuff to put in there, use SOAP and stick it in the SOAP headers. It's wishful thinking to assume we'll be able to reuse our HTTP semantics on other transports... and keeping HTTP semantics out of the entries makes Atom easier to use on other transports. > > >> 1. remember the last time I updated, and include the same value for > >> <atom:updated> > > > > My client loads up a DOM when it wants to edit, and changes the parts > > it understands. > > Right, but someone still has to remember what I sent for > <atom:updated> last time... hold on; are you assuming that you're > always going to go get the entries collection before you do a PUT to > overwrite an entry, so then you'll know the atom:updated? I'm > beginning to be convinced. Either I remember both the URI to PUT to > and the last atom:updated, OR I look at the collection to fetch the > atom:updated. I am assuming that editing Atom entries over HTTP requires storing at least the URI, Last-Modified and/or ETag, and the message body. If someone is having overwriting problems, they probably aren't using the right If-* headers. If you're talking about ordering problems when interacting with date-ranges, I guess you can sympathize with dropping ordering and ranges from my draft. > Then I'd want to explicitly document in the APP that > if I PUT an entry that's different but the <atom:updated> is the > same, that means I don't consider the difference significant in the > sense of http://www.atompub.org/2005/08/17/draft-ietf-atompub- > format-11.html#rfc.section.4.2.15 > > Or did I totally miss your point? I think that last paragraph is obvious. For example, JavaScript implementations are *required* to know what time it is, and it was trivial to have my implementation bump the atom:updated element on the way out. I'm not sure how I would expose "insignificant" updates to my users. The only situation I've encountered where I couldn't ascertain the correct time was writing an Atom client on a T-Mobile phone. T-Mobile doesn't provide network time, so I couldn't do so. About a month after I wrote that, T-Mobile firewalled port 80... so I've learned not to give a shit what happens in mobile phone walled-gardens. > > >> 2. have an explicit signal as in PaceInsignificantUpdate > > > > Reasonable extension header. > > See above, I want it in the XML. But I'm beginning to be convinced > that you could get away without this. > > >> 3. leave atom:updated out of the body you PUT, then document in the > >> protocol spec that this has the semantic that the client does not > >> consider this significant. > > > > No. See [AtomFormat]. > > Actually, there's a big issue here that we've never discussed. When > you POST/PUT an atom:entry in the APP context, it is plausible to > think that we could specify things in such a way that that atom:entry > is not in fact conformant to all the rules of atom-format; i.e. it's > an atom:entry but it's not an Atom Entry Document. Maybe surprising, > but not impossible. Oh sure, there's a large area of rough on either side of the narrow fairway, but we can't purport to have specified an interoperable protocol if we try to document that. We can write a simple experimental protocol and document what's happened in 2006/2007. Robert Sayre
