Bug #3739

Feeds and atom:updated

Von Lars Heuer vor mehr als 7 Jahren hinzugefügt. Vor mehr als 7 Jahren aktualisiert.

Status:New Beginn:2010-10-18
Priorität:Normal Abgabedatum:
Zugewiesen an:Graham Moore % erledigt:

0%

Kategorie:-
Zielversion:-

Beschreibung

Atom has no specific rules for the atom:updated value:

http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.updated

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.

[...]
Publishers MAY change the value of this element over time.

Should SDShare be more restrictive?
  • Should the overview feed's atom:updated value reflect the time of the last updated snapshot/fragment of all collections?
  • Should the collection feed's atom:updated value reflect the time of the last updated snapshot/fragment within that collection?
  • Must the atom:updated element of the snapshots feed reflect the time of the last updated snapshot?
  • Must the atom:updated element of the fragments feed reflect the time of the last updated fragment?

Historie

Von Christoph Ludwig vor mehr als 7 Jahren aktualisiert

I would not change the atom:updated element in the overview and collection feeds when one of the (indirectly) linked feeds is updated. I don't think it's necessary to prohibit such an gratuitous change, though. On the other hand, it may be reasonable to explicitly require that the atom:updated value is not before the most recent date when an entry was added or an atom:link element in one of the entries was changed.

In case of a snapshot or collection feed, the feed's atom:updated element should indeed have the same value as the most recent entry's updated field. Here it also makes sense to prohibit modification of some elements in the feed, e.g. sdshare:ServerSrcLocatorPrefix or sdshare:TopicSI. If one of these values changes, then. in general, it's unreasonable to expect a client to first realise what changed and then apply the resulting changes to its own store. In the best case, it can do a clean replacement.

Von Lars Heuer vor mehr als 7 Jahren aktualisiert

Regarding the overview feed / snapshots feed / fragments feed: I agree.

Regarding the collection feed: I think it would make sense if the snapshots feed entry and the fragments feed entry would reflect the timestamp of the last updated snapshot or fragment.
And if the entries are forced to reflect the recent timestamp, it would be logical if the collection feed's atom:updated is (pseudo code):

  max(entry/link[@rel='http://www.egovpt.org/sdshare/fragmentsfeed']/../updated, entry/link[@rel='http://www.egovpt.org/sdshare/snapshotsfeed']/../updated)

Clients wouldn't be forced to fetch the fragments feed and the snapshots feed but get all necessary information about recent updates from the collection feed.

Von Christoph Ludwig vor mehr als 7 Jahren aktualisiert

I don't think that a modification of the collection feed's atom:updated element would cause harm, but I don't see a compelling reason to do so.

A typical client will initially download a snapshot and then regularly pull any new fragments. For that it will GET the overview feed and the collection feed with an if-modified-since HTTP header to make sure it has an up-to-date fragment feed URL. (This URL is unlikely to change often, but the client can never know.) It then fetches the fragment feed, again with an if-modified-since header.

Assume that the collection feed's atom:updated element is not changed when there are new fragments or snapshots. If there is no new fragment, then the client receives three 304 HTTP codes in a row and is done without any expensive operation. If there is a new fragment, then it has to parse the fragment feed only.

On the other hand, assume a new fragment or snapshot causes a mandatory change in the collection feed. If there was no change at all, then the client can stop after two 304 HTTP codes. If either the snapshot feed or the fragment feed changed, then the client has to parse the collection feed as well, only to find that the fragment feed's URL is almost always the same as before. It then continues with a conditional GET request of the fragment feed; if it was the fragment feed that changed (the more likely case), then it has to parse the fragment feed as well.

In effect, the mandatory modification of the collection feed's atom:updated element means that clients save 1 HTTP request with HTTP code 304 if there was no change, but it costs them the additional parsing of the collection feed (with typically only two entries) if there was a change. What's better (performance-wise) depends on the frequency of new fragments.

Either way, I expect the difference to be small. I therefore don't intend to keep arguing this detail.

Auch abrufbar als: Atom PDF