My Journal RSS with full page text is being syndicated by PlanetEmacsen. When I look at my pages in that list, however, I see that they seem to be in random order. I figured out why:
The Oddmuse:Journal RSS Extension produces an RSS feed with the same pages in the same order as on my Diary page. Thus, pages should be sorted by the date in their title. If I make minor changes to the pages, their *timestamp* is updated, however. And the timestamp is passed on to the RSS feed (as pubDate element), and Planet Emacsen resorts all pages received based on their pubDate.
What should I do: Take it like a man, or lie about the pubDate by providing the pubDate of the last *major* change?
Assuming I could design my own feed aggregator that expected to deal with wikis, how would I design it? Wikis really don’t afford strict chronological reading. As pages are edited, you need to provide some context for the edit. And most people don’t like to read a steady stream of diffs coming their way... So it would have to send edit pages, or parts of pages, maybe highlighting the changes inline instead of providing a diff at the beginning? I’m not sure. I like the diff at the beginning when browsing pages from Recent Changes. And from there I can always go back and click on the *history* link. Perhaps I should link to the history from the diff at the top of the page. (You only get to see the diff if you click on the *diff* links on Recent Changes, or if you include diff=1 in the parameters for the RSS feed!)
Currently the default for Recent Changes is to list only major edits. This would suggest that my feed for the planet should also use the pubDate of the last major change.
(Some discussion about RssVisualization moved...)
#Oddmuse #Wikis #Planet
(Please contact me if you want to remove your comment.)
⁂
I had a similar challenge over this on my wiki; I’ve mixed tags, page clusters and weblog-3.pl together and use bits of the rss code to build a monster which pulls elements with the same cluster/tag and displays them in reverse date order.
Now, months later, I don’t know *what* I was thinking 😄 But hey, it works, kinda.I can use real page names (ie, no date in the title) and still get a bloggish set of entries. The code is ugly, sprawling and I’m sure I could re-write it much better. I was just amazed it worked first time, so left it well alone 😄
Anyhow. It does mean that if I edit a post as a major change it gets “promoted” to the top of the list again. I kept meaning to go back and fix that, but didn’t. I just mark all edits as a Minor change unless I explicitly want it to go to the top again. That works well enough for me.
I’ve put a copy of the blogging by cluters code here. Along with the Last Edited module (to put the date under the title), it works ok.
Maybe the solution is to use the Creation Date module to put the date into the RSS instead of using the last edited date. Hmmmm......
– GreyWulf 2006-12-12 13:21 UTC
---
I guess an alternative for the people who use dates in their page names would be to add code to journal-rss.pl that will try to find a date in the page title, and convert it to a timestamp instead of using `$Page{ts}`. People extracting the date from the RSS feed will see that I write all my pages at 0:00 GMT, but other than that, it would make sense, more or less.
if (GetParam('match', '^\d\d\d\d-\d\d-\d\d') eq '^\d\d\d\d-\d\d-\d\d' and $id =~ _^(\d\d\d\d)-(\d\d)-(\d\d))
= POSIX::mktime(0, 0, 0, $3, $2 - 1, $1 - 1900); }_
But then:
↘
<title>2006-12-12</title>
<link>http://localhost/wiki/2006-12-12</link>
<description>Hello. </description>
<pubDate>Mon, 11 Dec 2006 23:00:00 GMT</pubDate>
↗
Return to the wonderful world of GMT vs. localtime! 😄
if (GetParam('match', '^\d\d\d\d-\d\d-\d\d') eq '^\d\d\d\d-\d\d-\d\d' and not GetParam(’ts’, 0) and $id =~ _^(\d\d\d\d)-(\d\d)-(\d\d))
= ’’; # force GMT for mktime! $Pagets}_
– Alex Schroeder 2006-12-12 14:36 UTC
---
Now that I think about it, maybe I should use 23:59:59 instead of 0:00:00 for my posts so they stay on top! ;)
– Alex Schroeder 2006-12-12 15:20 UTC
---
The alternative would be to filter Recent Changes appropriately... Hm.
– Alex Schroeder 2006-12-12 15:24 UTC
---
These sorts of problems were part of the motivation for Atom having both atom:published and atom:updated. I can try to fiddle with the planet to see if it can sort on different date fields...
– EdwardOConnor 2006-12-12 17:47 UTC
---
Well, I can do the same kind of fiddling on my side. No need for you to change anything. The question is: What would you expect? I think what you would expect is that my articles appear at the top of the list on Planet Emacsen, and move down as time passes. If the article gets revised, paragraphs added, typos fixed – you want those changes to be reflected on Planet Emacsen, but you don’t really want to see my article pop to the top of the list again, right?
That’s how I implemented it now.
– Alex Schroeder 2006-12-13 00:03 UTC
---
In Atom, atom:updated is only supposed to be changed on “significant” edits – I’d expect such edits to cause the article to pop to the top. If the edit wasn’t significant, the idea is that atom:updated wouldn’t change.
Relatedly, the Atom WG has app:edited in the protocol draft – it should change every time something is edited, not just on “significant” edits.
– EdwardOConnor 2006-12-13 00:15 UTC
---
After much hesitating I decided that you are right and changed the code again. It now works like atom:updated.
– Alex Schroeder 2006-12-21 21:48 UTC