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.
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. 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?
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.
-Tim
