No wonder RSS replays every day on smaller wikis: https://bugzilla.wikimedia.org/show_bug.cgi?id=20601 (Do not put "diff generator" comments into feeds) You won't be affected on larger wikis, but with wikis with just a couple of changes a week, you'll go out of your mind... can someone please implement the fix?
On Tue, Sep 15, 2009 at 5:11 PM, jidanni@jidanni.org wrote:
No wonder RSS replays every day on smaller wikis: https://bugzilla.wikimedia.org/show_bug.cgi?id=20601 (Do not put "diff generator" comments into feeds) You won't be affected on larger wikis, but with wikis with just a couple of changes a week, you'll go out of your mind... can someone please implement the fix?
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
As I stated on the bug, your patch isn't viable. We need a way to be able to switch debug output on/off depending on whether it's desired. Silently removing it isn't the solution!
-Chad
Chad wrote:
On Tue, Sep 15, 2009 at 5:11 PM, jidanni@jidanni.org wrote:
No wonder RSS replays every day on smaller wikis: https://bugzilla.wikimedia.org/show_bug.cgi?id=20601 (Do not put "diff generator" comments into feeds) You won't be affected on larger wikis, but with wikis with just a couple of changes a week, you'll go out of your mind... can someone please implement the fix?
As I stated on the bug, your patch isn't viable. We need a way to be able to switch debug output on/off depending on whether it's desired. Silently removing it isn't the solution!
I don't think it's a big deal. That debug output was added to isolate a bug that was fixed long ago. If it recurs, the user can patch the debug output back in.
Fixed in r56406.
-- Tim Starling
jidanni@jidanni.org wrote:
No wonder RSS replays every day on smaller wikis: https://bugzilla.wikimedia.org/show_bug.cgi?id=20601 (Do not put "diff generator" comments into feeds) You won't be affected on larger wikis, but with wikis with just a couple of changes a week, you'll go out of your mind... can someone please implement the fix?
I think the bug may be misstated. The changing "diff generator" comment should not be a problem at all. The problem you have is most probably caused by bug 7346[1]. While that bug is not fixed, I'd suggest you to switch to the Atom feed, which do have an ID string (and a proper 'updated' tag). If you still have problems using the Atom feed, then the problem is in your reader.
RSS feeds have too many problems, and I'd avoid them whenever possible. The only date information available for entries is <pubDate>, which represents the "publication" date, i.e., when the entry was made available. For a wiki or any other dataset that may have constant updates this is hopelessly inadequate, and thus readers have to use very unreliable tricks like checksumming the contents of the <description> tag to detect updates.
Atom feeds, on the other hand, has both <published> and <updated> tags for every entry, so readers are provided with enough information about when the item was published, and if/when it was last updated. The default Mediawiki feed implementation uses the <updated> tags in Atom feeds, which in RecentChanges is the date that event occurred (and does not change).
If you still insist in using RSS feeds, I give you an option: As part of creating one of my extensions[2], I had to create enhanced feed classes for MediaWiki, since the ones in includes/Feed.php were inadequate to my needs. I also created a compatibility layer that replaces MediaWiki feeds with these enhanced ones, and it includes the <guid> element in the resulting RSS feeds. If you want to try, install the extension and configure it like this:
require_once( 'extensions/Wikilog/WlFeed.php' ); WlFeed::$cfgOverride = true;
Tell me if this solves your problem.
Regards, Juliano.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=7346 [2]: http://www.mediawiki.org/wiki/Extension:Wikilog
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fabj.jidanni.org%2Findex.... says it is a valid feed.
"JFR" == Juliano F Ravasi ml@juliano.info writes:
Yes, in an ideal world we would all switch to Atom.
JFR> and thus readers have to use very unreliable tricks like JFR> checksumming the contents of the <description> tag to detect JFR> updates.
which work fine for every feed I've encountered except Mediawiki's, where someone left debugging on in the production version.
And readers will not necessarily stop comparing content just because there now is a guid.
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.
JFR> If you still insist in using RSS feeds, I give you an option: As JFR> part of creating one of my extensions
Nor why must we start using extensions, just because someone has left debugging turned on.
Nobody "left it on." It was part of the output and you're the first person to ever mention this as an issue.
-Chad
On Sep 15, 2009 6:45 PM, jidanni@jidanni.org wrote:
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fabj.jidanni.org%2Findex.... says it is a valid feed.
"JFR" == Juliano F Ravasi ml@juliano.info writes:
Yes, in an ideal world we would all switch to Atom.
JFR> and thus readers have to use very unreliable tricks like JFR> checksumming the contents of the <description> tag to detect JFR> updates.
which work fine for every feed I've encountered except Mediawiki's, where someone left debugging on in the production version.
And readers will not necessarily stop comparing content just because there now is a guid.
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.
JFR> If you still insist in using RSS feeds, I give you an option: As JFR> part of creating one of my extensions
Nor why must we start using extensions, just because someone has left debugging turned on.
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedi...
jidanni@jidanni.org wrote:
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fabj.jidanni.org%2Findex.... 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.
JFR> In any case, would you tell me what are your feed reader software?
Yes, it's right there in the "URL" field of https://bugzilla.wikimedia.org/show_bug.cgi?id=20601 , i.e., http://article.gmane.org/gmane.emacs.gnus.user/12856 . http://jidanni.org/comp/configuration/.gnus.el is my dotfile.
Yes I would love for https://bugzilla.wikimedia.org/show_bug.cgi?id=7346 to get fixed.
But those in charge have different priorities.
So maybe my simple "somebody forgot to turn off the debugging" slogan might meet with some action on https://bugzilla.wikimedia.org/show_bug.cgi?id=20601
If they fixed that then I wouldn't need the arms race of workarounds.
mediawiki-l@lists.wikimedia.org