Diff: WikiRssFeedIssues

Differences between version 7 and previous revision of WikiRssFeedIssues.

Other diffs: Previous Major Revision, Previous Author

version 7

The Issue with Wiki RSS Feeds

This began as a response to a post on Chris Siebenmann's wiki about blogs versus wikis. Chris asserts that blogs have an advantage when it comes to presenting and tracking changes. I have to agree with this, but I think the issue is mainly an implementation weakness of wikis. Wikis could present better change tracking interfaces, if the current wiki engines were improved.

I use phpwiki for my site www.hollenback.net, and one problem is it it has a terrible rss feed. All the feed gives you is page summaries, and those are just the one-line comment the page editor makes when submitting a change. Note that some other wiki engines hopefully have other, better rss engines - if so I welcome comments to this post.

So I have the wiki where I do my blogging, but I can hardly do anything useful with the rss feed. However, I believe this is an implementation detail, not a fundamental issue with using wikis for blogging. Further I think that this could be fixed is a way that preserves the wiki concept. I don't think you have to make your wiki into a blog to get better rss feeds.

Instead of just the change description, my wiki should be able to output the page content. I'd like it to output the first header and paragraph of every changed page by default, along with an option to output the entire content of the page. This is easy to derive since the wiki engine knows the page content and structure. The wiki also knows which pages have changed for a given date range.

I also wish my wiki rss feed offered categorization. If there were just some simple way to tag pages with keywords then you could construct category rss feeds easily. That would bring my wiki up to parity with blog categorization. The user interface for this could be implemented in one of several ways:

• Allow a special category: keyword wiki tag to appear by itself on a line, and use that when constructing category urls.

• Present a separate category dropdown list for each wiki page.

  • Every time you edit the page, you have the option of selecting a category from the list.

• (the most wiki-like idea I can think of) Use the the wiki page path to derive the category.

  • If a page is a child of the sysadmin page, put it in the sysadmin category.

Note that twiki does implement the last item, because it supports per-category (web, in twiki lingo) RSS feeds. However I dislike this implementation because it enforces too much separation between wiki categories and is really intended for completely separating incompatible content.

Any of these user interface options are relatively easy to implement, and would go a long way towards resolving the biggest problem I have with the rss feed of my website. The key thing I want is a way to construct category rss feeds, so example I could provide a sysadmin rss feed to Planet Sysadmin that wasn't polluted with my private ramblings. The downside I see with all of this is it requires back end support. You probably want to keep a precomputed database of pages and categories, otherwise you have to walk all the pages every time you generate an rss category feed.

As I said, my big problem is that all of this doesn't exist for the decrepit wiki engine I'm using. However I see no reason it couldn't be relatively easily implemented on any wiki engine.

There are many other issues with using wikis as blogging engines, but I do continue to believe that these are implementation details and not fundamental problems the wiki methodology. For example, another thing I hate about blogging on a wiki is that I can't hide posts that are a work in progress - once I put them on the wiki anyone can see them. This forces me to compose posts somewhere else and paste them into the wiki when done. Again, that's just an implementation detail as a wiki engine could easily include a 'hide this page' button. These problems are solvable if someone devotes some time to work on them.