> > >(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
