Sam Ruby wrote:
> It seems to me that instead of adding a dynamic content flag, having
> a separate id element (or in RSS 2.0's case, utilizing the guid
> element) would be more to the point.
Relying on a GUID alone only works if you implement a policy that
says that you are only interested in seeing content with "new" GUIDs and you
are willing to ignore any "updates" to previously seen entries/items.
Similarly, relying on atom:id + atom:updated implies a policy of only being
interested in content changes which are explicitly flagged by the publisher
as being "worthy of notice." These are certainly appropriate policies for
*some* aggregators addressing *some* user needs. However, other aggregators
implement different policies which address other user needs. For instance,
many aggregators will update their content stores whenever *any* change
occurs in an item whether or not the GUID or Atom:id has changed. Some of
these aggregators will flag any change as a "new or unread" entry. (which I
think is a really stupid policy...) Others will, like Gush, distinguish
between "new" items and "updated" items. (I think this is much more
sensible, others will say it is overly complex and unnecessary.)
Conceivably, once Atom is released, some aggregators will wish to record
three states for an entry: "new", "major update" and "minor update." (I
would support anyone doing this, others would not.)
To understand this issue and many other syndication issues, it is
vital that you try to consider the full range of policies that are
implemented by aggregators and that you try to look beyond your personal
preferences. Please try to understand that this isn't a simple issue -- at
least not from the point of view of a channel intermediary like PubSub. As
was recently pointed out, a very large percentage of the HTTP specification
covers issues related to proxies (which is very much the role that PubSub
plays.) The same is true of the State Management (Cookie) RFC. I remember
that when we were working on that RFC, proxy issues were just about the
*only* thing we discussed... Problems which are "simple" in point to point
networks become much more complex when you introduce intermediaries.
Frankly, I really wish that we had done the "blog architecture" work
many months ago so that we would all have a shared understanding of the
system-wide issues and components rather than the widely divergent personal
and partial views that are obvious in many our conversations today...
bob wyman
