> > >(Drawback: the description reflects the current > > > file and not the cited revision.) > > > > I'm not sure if I like this idea for just the drawback you > > mentioned. > > The RSS feed already has this drawback. It only reports the most > recent edit for each page, and only shows the most recent description > of that page. But... right. I don't like the current solution either ;-) that's why I thought about the diff aproach... > I'll just look forward to your rsort() patch. It's in. I changed the format of the returned array a little bit. If any plugin uses the getRecent function it needs some adjustment. Esther? Chris? Do we have plugin's relying on getRecent? I think so but I'm not sure. > (BTW, you have the feed author/email fix in file joe050916a.patch, but > it might be wise to wait 'til after the release to post the patch so > we can get some experience using it with RSS/Atom clients.) Too late. It's in already. But I don't think it will make any trouble - AFAIK most aggregators don't do validation anyway - as long as the XML compliance is given we should on the safe side. > For example, I'm already using DokuWiki as a CMS that provides an RSS > feed subscription for the site's content changes. If you constrain > the contributors to just a few logged-in people, then it only takes a > few tweaks to make it seem like a regular web site. But the web site > authors have the ease-of-use of a wiki with which to maintain the > site. They do need control over RSS feed quality, though. ;-) I'm aware of the various non-Wiki uses and try not to hinder them, but I have to keep an eye on the feature-creep. To all of you reading: all things mentioned yesterday are in now. Please do some last testing. I will release tomorrow evening. Andi