ikiwiki/doc/todo/recentchanges.mdwn

* Why isn't it statically-genereated, but generated dynamically by CGI? It
  seems like it could be beneficial to have it rendered in the post-commit
  hook, just like everything else in the wiki. 

  > I hope to statically generate it eventually, currently the problem is
  > that it takes at least several seconds to generate the recentchanges
  > page, and adding several seconds to every page edit is not desiriable. If
  > the time can be reduced it could be done, I'm also not adverse to
  > adding an optional way to statically render it even at the current
  > speed. --[[Joey]]

* Also, is it planned/desired that recent changes generate the same
  information in RSS feed format? This seems like it could be a useful way
  to keep track of the wiki as a whole. 

  > This is used by various interwiki type things, I think, so should be
  > done.. --[[Joey]]

* Lastly, would it be possible to use the recent changes code with a
  pagespec? I understand this sort of infringes on territory covered by the
  inline plugin, but the inline plugin only puts a page in the RSS feed
  once, when it's created, and I imagine some people -- some deranged,
  obsessive-compulsive people like myself -- would like to know about the
  changes made to existing pages as well as newly-created pages.

  > That would work rather well for pages like [[todo]] and [[bugs]], where
  > you want to know about any updates, not just initial
  > creation. --[[JoshTriplett]]

  > Of course you can use email subscriptions for that too.. --[[Joey]]

  >> I have more thoughts on this topic which I will probably write 
  >> tomorrow. If you thought my other patches were blue-sky, wait until 
  >> you see this. --Ethan

OK, so here's how I see the RecentChanges thing. I write blog posts and
the inline plugin generates RSS feeds. Readers of RSS feeds are notified 
of new entries but not changes to old entries. I think it's rude to change
something without telling your readers, so I'd like to address this.
To tell the user that there have been changes, we can tell the user which
page has been changed, the new text, the RCS comment relating to
the change, and a diff of the actual changes. The new text probably isn't
too useful (I have a very hard time rereading things for differences), 
so any modifications to inline to re-inline pages probably won't help,
even if it were feasible (which I don't think it is). So instead we
turn to creating diffs automatically and (maybe) inlining them.

I suggest that for every commit, a diff is created automagically 
but not committed to the RCS. The page containing this diff would be
a "virtual page", which cannot be edited and is not committed. 
(Committing here would be bad, because then it would create a new
commit, which would need a new diff, which would need to be committed, 
etc.) Virtual pages would "expire" and be deleted if they were not 
depended on in some way.

Let's say these pages are created in edits/commit_%d.mdwn. RecentChanges
would then be a page which did nothing but inline the last 50 `edits/*`. 
This would give static generation and RSS/Atom feeds. The inline 
plugin could be optionally altered to inline pages from `edits/*` 
that match any pages in its pagespec, and through this we could get
a recent-changes+pagespec thing. You could also exclude edits that have
"minor" in the commit message (or some other thing that marks them as
unremarkable).

You could make an argument that I care way too much about what amounts
to edits anyhow, but like Josh says, there are use cases for this. 
While this could be done with mail subscriptions, I can think of sites
where you might want to disable all auth so that people can't edit
your pages. --Ethan

> I really dislike all Wiki engine recentchanges pages.  They all tend to be
> fairly machine readable, but confusing for non-wiki users to grok.  And I've
> yet to see an _attractive_ recentchanges implementation.  IkiWikis' is no
> better or worse than the others.
>
> I really like the frontpage of [Bill
> Seitz](http://webseitz.fluxent.com/wiki/FrontPage) as an recentchanges
> format.  Note how he uses some clever css to show changes in different
> sections of the website.  I modeled my own
> [recentchanges](http://xtermin.us/recentchanges) page page on his ideas.  This
> probably isn't appropriate for non-WikiLog style setups, but is this
> something closer to what you what was requested?
>
> BTW: My recentchanges plugin does not seem to add a lot processing time
> to compiling.  Then again, I'm not pulling changelog message from the RCS 
> backend.
>
> -- CharlesMauch

---- 

Here's a full design for redoing recentchanges, based on Ethan's ideas:

* Add a recentchanges plugin that has a preprocessor directive:
	\[[recentchanges num=100 pages=* template=recentchanges.tmpl]]
  If put on the [[recentchanges]] page, this would result in up to 100
  recentchanges/change_$id.mdwn files being created.
* Which means the plugin has to store state and use a checkconfig hook
  or the like to create the requested pages (and delete old ones) when
  the wiki is rebuilt and when the post_commit hook is run.
* Then it's a simple matter of using inline on the recentchanges page
  to display the changes. (With a special template to display nicely.)
* Rss/atom comes for free..
* So drop mail notifications.
* If someone wants to subscribe to notifications for only a subset
  of pages, they can either filter the recentchanges in their rss
  aggregator, or they can set up their own page that uses the recentchanges
  directive for only the pages they want.
* The `rcs_notify` functions will be removed.
* To add diffs, another plugin can add a pagetemplate hook that calls
  a `rcs_diff`. (optional)
* So to update the changes files, just call `rcs_recentchanges`, create
  files for each new id, and delete files for each id that is no longer
  included.
* The cgi support for recentchanges can be dropped, or moved to a different
  plugin.

I'm unsure how fast this will all be, but by using regular pages, there's
cacheing, at least. The main slowdown might turn out to be the inlining and
not the generation of the changes pages. The current cgi recentchanges
code saves a tenth of a second or so by memoizing htmllink, an optimisation
that won't be available when using the more general inlining code.

An obvious optimisation, and one implied by this design, is that each change
file is only written once. This assumes that the data in them doesn't ever
change, which actually isn't true (svn commit messages can be changed), but
is probably close enough to true for our purposes.

Another optimisation would be to htmlize the change files when they're
written out -- avoids re-rendering a given file each time a new change is
made (thus doing 1/100th the work). 

Links in the change files to the changed pages will need special handling.
These links should not generate backlinks. They probably shouldn't be
implemented as wikiliks at all. Instead, they should be raw, absolute 
html links to the pages that were changed.

Only problem with this approach is that the links break if the changed
page later gets deleted. I think that's acceptable. It could link to
`ikiwiki.cgi?do=redir&page=foo`, but that's probably overkill.

--[[Joey]]

[[done]] !! (in this branch at least :-)