Tags:
archive_me1Add my vote for this tag create new tag
view all tags
Several RSS readers do not show all entries seen in the WebChanges list: repeated updates to the same topics get lost!

Problem

List of "broken" readers

List of readers known to work

  • add here

RSS readers keep a FIFO list of newest entries. Several readers cannot identify changes to an existing topic, obviously because title and summary don't change. Readers which look at the date should be able to identify the new entry.

Problem first described in topic FeedReader, then in TWikiSyndication, text moved over here:

Recently, I switched from FeedReader to Bloglines. Now I realized, that it is plagued by the same problem:
New revisions of the same topic don't count as change! I missed quite a few discussions this way frown
What is the experience with other RSS clients? If this is a common problem, the fix for FeedReader should go onto TWikiDotOrg!

From WebStatistics:

10855 WebRss
2204 WebHome
1236 WebChanges
926 CairoRelease
Quite a few people seem to use the RSS feature. Are FeedReader and Bloglines the only clients, which do not recognise new revisions of a topic already in their list?
Testcase
watch WebChanges and your RSS reader in parallel. If WebChanges reports a new revision of a topic already in your changes list, do you get a new notification?
Question
does everybody agree, that you want a notification in this case? I hope so.

-- PeterKlausner - 22 Sep 2003

ArthurClemens writes in ReasonForTwikiOrgSlowPerformance: (sometimes alreay read topic links that are updated are not placed at the top of the list. Must be a bug with my NetNewsWire). This is the same symptom as in FeedReader or Bloglines, where this happens consistently, once an entry exists in the list. -- PeterKlausner - 25 Sep 2003

Is it really a problem?

There is nothing wrong with the info that RSS spits out. Looking at the xml that my newsreader loads after an update, the topic list in the RSS xml lists topics in the correct (new) order, the items are listed in this order, and also the dates (minutes) are correct. Still the newsreader insists in putting them in the same old (now wrong) order. That concludes it must be in the newsreader.

-- ArthurClemens - 25 Sep 2003

The XML is ok, yes. But as mentioned in FeedReader:

  • Probably depends on the definition of "new". New title or changed attribute of existing title?
This is at least debatable and 3 implementations decided: an entry where only the date stamp changed, is not new.

-- PeterKlausner - 01 Oct 2003

Solutions

Insert revision

The simple change of WebRss as described in FeedReader, i.e.: include $rev in the item's title.

Insert actual changes

Alternatively do some scripting to deliver first part of the change as desciption -- discussed in other topics like NewEmailNotificationSystem

-- PeterKlausner - 25 Sep 2003

Insert author

  • Or change the topic title in the RSS to: topic (author)
    • that way you can see who has made the last edit in the 'title', and the newsreader will probably update normally (i.e. put the topic at the top).
      • yes, this is very nice; that's what I actually use <nop>$wikiusername despite the ugly Main.UserName spelling. Or does BeijingRelease offer a variable without Main. prefix?
      • still, this doesn't fully resolve the issue: if the same author updates a topic a few days later, the "broken" readers will miss it -- PK
        • I know a better solution: add a timestamp to the summary (the topic change date). Should only need to concatenate these on RSS. -- ArthurClemens - 01 Oct 2003
          • makes sense, much more readable; but doesn't work in FeedReader frown I already had forgotten, why I crammed everything into the title: because it doesn't care about changed date and description and revision and probably most other attributes... -- PeterKlausner - 01 Oct 2003
            • One more stab: use a topic url with a time parameter, as when editing: topic?t=1065041972 -- ArthurClemens - 01 Oct 2003

Insert revision date in topic link

This does indeed work for NetNewsWire. In WebRssBase, change the link to:

&lt;link&gt;%SCRIPTURL%/view%SCRIPTSUFFIX%/$web/$topic?t=$isodate&lt;/link&gt;

I just made the change on twiki.org, as a general test. Please notify if this works or breaks your feed.

-- ArthurClemens - 02 Oct 2003

Very good! That did the trick for FeedReader. The updates in BlogLines look much better but I can't force a poll, so I'm not 100% sure. I will report, if the problem crops up again. But from a logical point of view, this should really fix it, thanks a lot!

-- PeterKlausner - 02 Oct 2003

No complaints yet? The only thing is that topics saved with "minor changes" do show up now.

-- ArthurClemens - 13 Oct 2003

No complaints! You can check yourself here: http://www.bloglines.com/search?q=twiki

Ad minor changes: I think they always showed up. This checkbox is responsible for adding topic name, author and date to the .changes file (or not). WebRssBase uses a %SEARCH, which doesn't know about this file. So your observation might come from "minor changes" done after a major edit, which made into the reader's entry queue. BTW: in NewEmailNotificationSystem I proposed to make this selectable.

-- PeterKlausner - 14 Oct 2003

I mark this bug now as closed.

-- PeterThoeny - 19 Oct 2003

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2004-08-20 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.