[Mediawiki-l] No wonder RSS replays every day on smaller wikis

[Juliano F. Ravasi]

jidanni at jidanni.org wrote:
> http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fabj.jidanni.org%2Findex.php%3Ftitle%3DSpecial%3ARecentChanges%26feed%3Drss
> says it is a valid feed.

Being valid doesn't mean the feed makes logical sense. The <guid> tag is
optional because RSS can be used for a lot of other things than just
MediaWiki RecentChanges. For some of these things, only a plain list of
items with no unique identification is desired (live GPS tracking, for
example). Note that RSS also does not mandate a <pubDate>, but would you
argue that a RecentChanges feed is correct without a <pubDate>?

I'd argue that not having <guid>s in RecentChanges RSS feeds is the bug
here, since we have a list of items that are uniquely identified (each
change is unique and can be unambiguously referenced). As I said, in
fact, that is bug #7346.

> which work fine for every feed I've encountered except Mediawiki's,

How many of these feeds list unique entries without providing <guid>s?
Even though I really doubt that you have seen that many feeds, this is
called "anecdotal evidence". You may see a million cases that support
your point-of-view, yet, that doesn't make it correct.

The behavior of your particular software (checksumming the contents of
an entry) is not condoned by any specification. If an entry doesn't have
a <guid>, even if the same identical contents are read from two distinct
requests, there is no guarantee that they are the same unique entry.

The description of a feed entry is not set in stone, it may change for a
number of reasons. The correct way to keep track of the changes of a
particular entry is through its unique identifier.

> And readers will not necessarily stop comparing content just because
> there now is a guid.

If a reader duplicates entries with the same unique identifier when the
contents of the entry change, that particular reader goes directly
against the recommendation of the specifications (or at least the Atom
specification, RFC 4287). The reader may, however, signal that a
particular entry was updated if another entry with the same id but a
different updated date is received (Atom).

> And we shouldn't be required to ask reader packages to implement an Atom
> version, because we can't use RSS anymore, just because someone left
> debugging turned on.

Your reasoning is strange. There is no need to require readers to
implement anything at all. If you need a feature that is provided by X,
and your product Y doesn't support that feature, you just use a
different product.

In this case, there is enough demand for Atom, and most (all?)
non-abandoned feed reader software support it.

And the "because someone left debugging turned on" is completely
irrelevant to the issue here.

> Nor why must we start using extensions, just because someone has left
> debugging turned on.

I offered you an option. I'm not telling you that you must start using
anything.

I guessed the problem you are experiencing is due to the lack of unique
identifiers, so I suggested you to test the extension, which replaces
the standard RSS feed with one that provides unique ids. That would tell
us precisely where is the issue.

In any case, would you tell me what are your feed reader software?

Regards,
Juliano.

-- 
Juliano F. Ravasi ·· http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96

"A candle loses nothing by lighting another candle." -- Erin Majors

* NOTE: Don't try to reach me through this address, use "contact@" instead.