create new tag
, view all tags
Replace or complement WebNotify with the following mechanism:

Add a ChangeNotifications page. Its contents should be just what WebNotify sends as an email attachment today.

Add the following headers:

  <meta http-equiv="refresh" content="10; URL=[same URL]">
  <meta http-equiv="pragma" content="no-cache">

The "refresh" part will automatically reload the page every 10 seconds; the "pragma" will make sure that the page is re-requested from the TWiki server.

The update frequency should be configurable by each user.

Since serving the requests can generate significant load, there should also be a configuration variable that specifies the minimum refresh interval for such pages.
There's a tension between server administration and users here. Administration will want to keep server load down (which means a long refresh cycle). Users will want to have a short refresh cycle.
I'm not sure how much of a real problem this is.

-- JoachimDurchholz - 18 Dec 2001

I'm not sure what problem you are are trying to solve.. unless your wiki is as active as a busy live chat site, nothing will happen other than the webserver getting a fake load. and if it is that busy, you don't want to have the link you re about to click on dissapear because your re-fresh period is up..

-- SvenDowideit - 06 Jan 2002

(See also ImmediateWebNotifyPerTopic.)

The new WikiRssExtension feature lets you have a desktop client (e.g. FeedReader) that notifies you almost instantly when there is a change. No TWiki code changes, just make sure you have WebRss pages in each web you want to track. So you can experiment with this right away. I find this quite useful even on a non-busy site - it's much easier to see when there are changes and is good if you are waiting for someone to reply to a comment you've made (simple ConversationTracking).

Mozilla users can also experiment with MozillaSidebar, which makes it easy to see recent changes from within the MozillaBrowser at least, but doesn't notify you the way FeedReader does.

As for the load implications - if we implement some BrowserAndProxyCacheControl features, the load can be reduced quite easily, by enabling browsers or RSS readers to cache the 'latest changes' for 5, 10 or 30 minutes. This involves TWiki setting HTTP headers, which is required to fix BackFromPreviewLosesText in any case. Note that META tags don't work with proxy caches, only browsers, but HTTP headers work really well - see BrowserAndProxyCacheControl for some articles on this topic.

-- RichardDonkin - 09 Feb 2002

I've just realised that the above idea about cache control to reduce server load would only work for MozillaSidebars, not for RSS - the problem is that the RSS reader is typically not a browser, and doesn't usually have any cache. Hence for larger sites it will be important to generate RSS feeds periodically into static files (e.g. a Unix cron job running every 10 minutes or so).

-- RichardDonkin - 16 Feb 2002

This looks like the right place to discuss my efforts. This is one of my first posts to Codev so please redirect me as needed. I am interested in the developments for real-time TWiki interfaces & RSS. I announced the #twiki IRC channel creation a few days ago. I hope some of you will drop by.

I'm a strong believer in the "bootstrap" methodology a.k.a. "eating your own dogfood." I have already set up a somewhat small but growing TWiki and some IRC summaries using the excellent Perl IRC Statistics Generator PISG software.

I look forward to participating in the discussions here.

-- GrantBow - 16 Oct 2002

I'm not doing much with RSS these days, but I think it is a valuable approach to getting instant notifications, which can of course be gatewayed into IRC, Jabber or whatever. The difficult part is deciding how notifications should work - ideally there would be a notification preferences setup, like on SlashCode, to let you say what sort of updates should be notified (e.g. update to page you created, or page you edited, or just 'this page' [on edit]).

Also, it should be possible to plug in different notification mechanisms, including email, RSS (custom feeds), IRC, etc. For communities such as the Hurd people who use IRC a lot, I can see how InstantNotification via IRC would be handy. For intranets, other tools might be preferred, including email. The biggest driver for a particular notification tool is of course 'what do people check at least every day?' - in my company it's email, hence a lot of discussions centre around this, but pluggable notifications would make TWiki much more powerful.

-- RichardDonkin - 17 Oct 2002

The idea of a flexible notification system sounds "spot on." It sounds like we're talking about redoing all notifications and that may be a big job. I'm unsure how easy or difficult it may be without exploring it. Are there other TWiki features that might serve as good examples on how to set this up?

The question you are using as a measure of success looks to have a few pre-suppositions in it. I can respect that but there are other possible interpretations. I believe the biggest driver for an information tool is "does this tool provide value when used?" The frequency of use can be open.

Let me use an example. Newbies drop in all the time on public IRC channels when they have a problem. We had someone today ask for help with the KoalaSkin. He may not use IRC every day, but does that mean there's no value in IRC? I think they are complementary technologies. Because we ultimately are dealing with human perceived value and social networks the full impact of a new tool will not be fully known until implemented (at least once) and used.

I wasn't a big IRC fan before working on the Hurd project. In using IRC a bit I find there are quantitatively and qualitatively different issues due to it's real-time nature. Email and Wikis are both asynchronous. Topic focus and thought are critical. This is far less important all the time on IRC. I suspect synchronous will become more important in the future for internal communications especially as media forms converge. I'm intrigued by IP Telephony.

Having said all this Richard, I totally agree that probably most companies currently use email as a primary communication method and anything we do should thoroughly support email use from the beginning.

-- GrantBow - 18 Oct 2002

Instant notification is really important to convince people to move from email over to a wiki.

I have been experimenting with FeedReader. And although the tool is buggy, closed source, the concept seems very attractive to users. It is, as if they get back some of emails value.

Clearly, there must be some way to define channels: I was thinking of a RssPlugIn which

  1. recreates output only if the data directory changes to reduce load
  2. honors the .changes file
  3. applies filter rules to the output. Filters could be:
    1. Form
    2. Last Author
    3. Any Author in history
    4. Parent (including indirect parent)
  4. caches results per filter being used

A completely different idea: post TWiki changes into a newsgroup. The mapping could be

Newsgroup Web
thread r1.1 of topic with no/WebHome as parent
sub-thread r1.1 of topic with parent
article beautified diff of last revision, maybe only additions?

There are some nasty details, though:

  • To have a clean diff, you could post only after the lock expired
  • New pages easily yield 2 revisions, which should be folded into on complete article to start a (sub-)thread
  • How to render? Leave it raw, wrap long lines or reformat it completely?


  • Newsreaders are optimized for scanning huge amounts of articles
  • They have sophisticated filter options
  • The display is fast and responsive
  • Yet another tool and infrastructure to understand and maintain
  • News/NNTP is not "kewl" any more; actually, right after my first experiments of automated postings, "they" announced to turn off our intranet news service...

-- PeterKlausner 18 Oct 2002

Great idea Peter. I assume you were talking about one of the topics that links to WebRss above but I'm unclear which one. I think a flexible notification infrastructure could easily be adapted to use NNTP as well. The nasty details you mention above can be worked out once we get into coding an implementation.

One thing from the pages I've seen is that I don't understand the full and complete status of a TWiki RSS implementation. OK, I think I see. It's been implemented already (WebRssBase) but the Codev brainstorm WikiRssExtension hasn't been turned into a feature that's being actively tracked. Can someone more knowledgeable please confirm this?

(Edited a few minutes later: yes it is! TWikiSyndication)

-- GrantBow - 18 Oct 2002

OK, I'm pretty confused. I'm getting a growing feeling that this was a topic that was outdated and I restarted it inapropriately. I apologize for speaking before doing my TWiki feature homework but I'm hoping someone will provide the context I'm missing. I also need to read more about RSS. One resource I intend to use to do so is this url. http://www.larkfarm.com/rss_resources.htm

To allow a flexible instant notification infrastructure based on the existing RSS functionality shouldn't we really be talking about expanding current RSS use by:

  • flexibility/choice of RSS reported data streams
    • per web (as is currently done)
    • based on topic metadata giving per topic and arbitrary
  • format of RSS "item descriptions" reported - the provided content
    • full pages
    • diff -u kind of output only
  • RSS client add-ons
    • email notification RSS client - accepts RSS feed and emails notifications
    • IRC RSS client - accepts RSS feed and outputs text on an IRC or other IM channel.
    • NNTP RSS client - accepts RSS feed and posts NNTP articles

-- GrantBow - 20 Oct 2002

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2006-01-24 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.