Henner Another question: What's about a global notify function? You add your name/email on a special page and will be notified wheother a page in the wiki has changed. Is this possible?

milky: Already working on this, but not on a *AllPageNotification, but instead something more like a weekly/daily diff newsletter or so, because I fear it would be far too annyoing to get notified about every single edit. However this will require cron-support, so I'm going to get a GlobalNotify ready too. Until then, you could check out our global RSS+Atom feed.

Henner Great!!

milky: It is relatively new, and I'm not sure if it really returns valid XML; but it's working good enough for me, I really like it. Though there are still a few pages, that I manually subscribe to (even if I got over 50 messages from the SupportForum and BugReports today *laugh*).

Jochen: I tried to get the RSS with Opera, but don't receive anything. RSS from another web page works. Are there any messages to get? I simply used http://erfurtwiki.sourceforge.net/RSS as adress, should be ok, shouldn't it?

MarioSalzer: Hmm, it worked for me. Depends on what RSS version Opera requested. If you just click onto that link you should get an error message; and if Opera doesn't send a correct Accept: header it will see the same and get no feed. Eventually our feeds are broken (invaid XML), not well tested all-over - I'll have to try this at home - which version are you using, btw?

Jochen: I tried with Opera 7.51. As http://www.opera.com/products/user/m2/rss/index.dml says: Opera supports all RSS formats starting from 0.91. And http://www.opera.com/windows/changelogs/750/ states: RSS 0.9x, 1.0 and 2.0 are supported.

I haven't any experience with rss but tend to believe opera and the working test rss feed.

MarioSalzer: Tested with 7.52 and it didn't work for me, since Opera does not know how to correctly request a RSS feed (or I couldn't find the way how to tell it in my version). But you can make it work for your version, if you go into plugins/lib/feed.php and change the ewiki_feed_type() function to always return($WHAT="RSS0"); This worked for me, and even seems to work with "RSS2", but "RSS3" is definitely not supported by Opera (but that format is a joke anyhow). I guess RSS1 is still broken for us, I'll better rip that out again.

As Opera goes, I'm not willing to support non-*TransparentContentNegotiation-capable HTTP clients, and they will have to fix how they handle RSS feeds.

mario: Ok, I've pestered them with a feature request, but also changed the Accept: header analyzation code to accept "*/*". It will meanwhile emit RSS0.9x for such ambigious requests, but that may be changed to RSS3.0 (plain text format) as it is a more human-friendly fallback. If Atom gets widely adopted, then */* will alias to Atom instead and thus Opera can't read our feeds again...

Jochen: I'm not really sure what you are trying to tell me but at least it works with Opera 7.51 at the moment:o)

The bad news is, that I was now able to notice that the rss feeds just deliver the start of the modified page - not the modified part. As this is nice to get informed about changes (no need to look at RecentChanges every 10 minutes and no flooded mailbox) it's not what I really need. So I'm looking forward to your "weekly/daily diff newsletter".

milky: The Atom feed contains some sort of diff. Sure it was better that way, but we first need the *DiffAlgorithm in our CoreScript, before we can use it everywhere. It is an essential feature (needed in a dozen places now), so it of course makes sense. Other WikiEngines store a diff in their database (PmWiki for example), which benefits them for such tasks, because they do not waste time recalculating diffs on every feed reader access (RSS can easily bring down larger websites, because many dumb clients check it on a hourly basis). We'll improve it, nevertheless.

*Henner: What's about this diff in php http://www.holomind.de/phpnet/diff.src.php? What's about implementing a plugin interface for diff so that the notify plugin can use this too?

Jochen: Doing a diff on every rss request? Oh no...I like my flat-files:o) I thought about something which is called by a cronjob every I-decide creating a diff-newsletter to the last run. Then anyone can request this as often as he likes. Btw: Are there any docs about how the rss-thing is working at the moment?

milky: Other WikiEngines store diffs in the database, and also RecentChanges is often a static page. Eventually we could do the same and thus buffer the required data for the RSS stream (or even write one to disk). As Andy pointed out, a *WordDiff would be even better, and what we really want is that the Wiki keeps track of visited page versions and highlights new text when you visit it next time -- there was a note about that on WikiFeatures:...

Jochen: Hmm. I really like to have the opportunity to use RecentChanges as dynamic page (who knows if i'll still have a cronjob next year?). But it would be nice to use just another plugin *RecentChangesStatic instead of *RecentChangesDynamic.

For the RSS or newsletter I personally would prefer to make it static, maybe every 8 hours. It's sure a good idea to keep the possibility to do this dynamic as it seems to be at the moment.

what we really want is that the Wiki keeps track of visited page versions and highlights new text when you visit it next time sounds really cool (I missed that note). But that would require a cockie per page, or someone would miss all changes on pages he doesn't view during the actuall visit.

Or one cockie storing a unique and never changing user id, but then the wiki must store each visit per id per page (can't imagine how this should work..)

milky: All very easy to do! You can very easily create a static RecentChanges page - by a cron job or via an edit hook, but then it was probably better to simply use the cache plugin (stores rendered html in DB).

For the *KeepingTrackOfVisitedPages I'm going to use some *UserVariables backend. Andy wrote some uservar_...() interfaces, but I still prefer a stupid $_EWIKI[] var blob, that get's loaded and stored back like a _SESSION blob (that's faster on disk than with our database). And then it gets fairly easy, you only need a line like '

$_EWIKI["history"][$id] = $data["version"];

' and there you have working *UserTracking. The code simply would cut the history down to 500 elements (not that we had so many pages!) and sort them by access count or date and be done (many ways to do it).

However the ChangesFromLastVisitHighlighting is a bit more complicated, because it must be done on the rendered HTML page. I haven't heard of any *WikiEngine that can do it (but this is often talked about feature).

Btw, cron-jobs can also be www-based only. We could simply hook it into RecentChanges or the FrontPage and let the GoogleBot activate it on a regular basis ("take advantage of your enemies" ;-). You know, it is possible to have PHP code that runs beyond page output (see register_shutdown_function() and $ewiki_plugins["shutdown"]).

Jochen: Sorry, still don't really see how this should work... I'm thinking of different groups of visitors

• a) coming by accident, will never come back, but must not waste storage capacity in ring buffer or so
• b) coming very rarely (twice a year), will probably not have much advantage of diff-highlighting, and should not waste storage capacity in ring buffer or so
• c) coming regularly but not every day, would like such highlighting
• d) coming very often (twice a day), would like such highlighting

now think of some (hundreds of) visitors of each group. And of small and midsize wikis (like this one).

What do you want to store? One entry per visitor per page like "visitor a viewed version 9 of page b"? And 500 Elements total? Or per visitor? Or per page? Perhaps I should simply wait and see:o)

jbw: Would not a cookie that stores the last time visted be good enough for 80-90% of the solution? At least then you could show them what was new since their last vist, and if they do not visit often enough to keep the cookie, then they lose the feature.

Jochen: Ähem, yes:o) Good and simply idea. Not as nice as without cookies but a lot less work. Let's discuss this on ChangesFromLastVisitHighlighting while this page is all about beeing notified without visit the page or the wiki.