Several RSS readers do not
show all entries seen in the WebChanges
repeated updates to the same topics get lost!
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
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
What is the experience with other RSS clients?
If this is a common problem,
the fix for FeedReader
should go onto TWikiDotOrg
Quite a few people seem to use the RSS feature.
the only clients,
which do not recognise new revisions of a topic already in their list?
- 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?
- does everybody agree, that you want a notification in this case? I hope so.
- 22 Sep 2003
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
where this happens consistently, once an entry exists in the list.
- 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.
- 25 Sep 2003
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
- 01 Oct 2003
The simple change of WebRss
as described in FeedReader
include $rev in the item's title.
Insert actual changes
Alternatively do some scripting to deliver first part of the change
-- discussed in other topics like NewEmailNotificationSystem
- 25 Sep 2003
- 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 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:
I just made the change on twiki.org, as a general test. Please notify if this works or breaks your feed.
- 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!
- 02 Oct 2003
No complaints yet? The only thing is that topics saved with "minor changes" do show up now.
- 13 Oct 2003
You can check yourself here:
Ad minor changes:
I think they always showed up.
This checkbox is responsible for adding topic name, author and date to the
file (or not).
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.
- 14 Oct 2003
I mark this bug now as closed.
- 19 Oct 2003