Many thanks to Lisa for the lengthy and detailed comments. I am just
replying to those comments relating to the parts of the spec I
understand best.
On 18 Oct 2006, at 01:40, James M Snell wrote:
*Synchronization*
I predict that some AtomPub authoring clients will attempt to
synchronize: to maintain an offline copy of the feed including all
its
MERs and media resources, and to keep that offline copy up-to-date.
Some will probably even allow offline authoring of new posts, and
offer
to synchronize when the client next goes online -- because of the
possibility of multiple authors, this may mean at times that the
client
would download new entries created by other authors, upload new
entries
created offline, and reconcile its offline copy of feed documents.
Because authoring clients will attempt to do this based on Last-
Modified
and ETag -- after all, the functionality is all there in some form or
another -- the spec needs a little more clarity on how the client can
rely on this working. Otherwise, some servers may omit features that
these authoring clients require, or implement them oddly. While I
would
never suggest repeating all the requirements from other specs (in
this
case HTTP), there are cases where clarity and interoperability are
greatly improved by at least referencing explicitly requirements from
HTTP. It's also possible to add new requirements based on
features in
HTTP, that apply to Atom servers alone.
I would be very happy to see some discussion of this in the spec,
especially if it normatively required the use of ETags for offline
synchronization.
I think synchronisation would be best dealt with by adding
functionality to sort the collection in different ways.
Currently the sort order is a SHOULD on atom:updated. That does not
allow clients to find the most recent edits. If there were a way to
sort the entries by app:edited one could find the most recent edits
quite quickly. Doing a HEAD on all the entries to find out which
changed by comparing etags is not really an option. For large blogs
such as Tim Bray's ongoing this would use up way to many resources
and take way too long.
[snip]
of HTTP (calendaring) than the general case. If HTTP
synchronization in
authoring cases were clearly defined and had not lead to years of
arguments since the last HTTP update, I would probably feel
differently
about just silently relying on the mechanisms in HTTP.
+1
In any case, I have very specific brief suggestions to cover
synchronization so that it's implemented more successfully than not.
- Consider adding a brief section offering clients non-normative
guidelines on synchronization. It doesn't have to limit server
behavior
so much as point out with green and red lights where the fairway is
(mixing transportation and golfing metaphors in my head)
- Make a few requirements of servers to avoid some of those HTTP
ambiguities. For example:
"The ETag or Last-Modified values for a member resource MUST
change when
any metadata in the resource changes, as well as text/content, and
this
includes "next" and "last" link relation values. The ETag or
Last-Modified values of a member resource MUST NOT change solely
because
an associated other resource (e.g. the media resource being an
associated resource to the media link entry resource) changed. "
+0.5. I would add that the ETag/Last-Modified values of a resource
SHOULD NOT change solely because of non-significant changes to the
infoset serialization of an entry (e.g. a different namespace
prefix is
used, or whitespace is added or removed, etc). I would also prefer
that
the ETag for a MLE change when it's associated media resource is
updated.
More open questions that might be related to synch or might have
relevance even for clients that don't do full synch:
- What is the relationship, if any, between the "atom:updated"
value and
the HTTP "Last-Modified" value. Can the "atom:updated" value ever be
later (greater) than the "Last-Modified" value? I believe it can
be the
same or earlier, but the spec doesn't disallow the broken case.
My assumption: There is no relationship. atom:updated should be
treated
as being entirely independent of Last-Modified.
yes.
It might be reasonable,
however, to define a relationship between Last-Modified and
app:edited.
No. In discussions on the topic of synchronisation it became obvious
that people wanted to have servers add properties to entries, such as
changing the number of comments for an entry, without this changing
app:edited.
A new app:modified would be the closest to something that could have
a 1-1 relation to Last-Modified. But there was a lot of push back
against app:modified as being too britle - ie. changing too often
(xml formating changes could cause app:modified to change)
- Is it clear whether the client MUST GET the entry after
modifying it
in order to have an accurate offline cache? (this was mentioned in a
post by Broyer Jul 13, but not in the document). I believe this
is made
clear already for the cases of getting the feed and also for
POST/create, but not for PUT/modify.
My assumption: Yes.
- Am I correct that the general assumption is that id's are there
to see
what entries are new, and URLs are there to see where to get
them? That
may mean that URLs could change, for a given ID -- Perhaps a
feature to
change the slug name of a image after attaching it. Is that
theoretically possible?
My assumption: Yes. ID's also help to detect changes so that old
entries
are not flagged as new when insignificant updates are made.
yes. Id's are there also to be able to find multiple versions of a
same document.
There are also efficiency considerations.
- The spec could require that servers MUST return either the ETag, or
the Last-Modified value, in any successful POST or PUT response. I
personally favour this so that clients can rely on it, though
obviously
other opinions are valid here.
I'd prefer this. My current implementation always returns the ETag on
the POST response.
I think it is a good idea to return Etags in the header. Well written
clients should keep track of them.
- I really liked the idea of putting ETag in the author's feed, as
discussed on the list but not appearing in the document, again for
efficiency.
Are you referring to the app:etag element?
This is no longer necessary, with app:edited. The client can keep
track of etags by keeping the http header info. There is no need to
place this in the entry itself.
Henry
