2 files changed, 66 insertions, 0 deletions
diff --git a/doc/bugs/git_mail_notification_race.mdwn b/doc/bugs/git_mail_notification_race.mdwn
index eddc0181e..3538b0764 100644
--- a/doc/bugs/git_mail_notification_race.mdwn
+++ b/doc/bugs/git_mail_notification_race.mdwn
@@ -44,3 +44,12 @@ edits. At least one of the two commits has to be a non-web commit.
 A related problem is that if two commits are made separately but then
 pushed in together, the commit code only looks at the HEAD commit, which
 is the second one. No notification is sent for the first.
+
+----
+
+Based on all of these problems with using the post-update hook, ikiwiki
+should be changed to use the post-receive hook, which provides enough
+information to avoid the assumuptions that led to these problems.
+Transitioning existing wikis to using a new hook will be interesting. Also,
+this hook is only present in git >= 1.5.0.7.
+--[[Joey]]
diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn
index d46c0d9a8..bdd7948e4 100644
--- a/doc/todo/recentchanges.mdwn
+++ b/doc/todo/recentchanges.mdwn
@@ -86,3 +86,60 @@ your pages. --Ethan
 > 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.
+* `rcs_getchange` is passed a change id (as returned from rcs_recentchanges)
+  and a partially filled out HTML::Template and fills out the remainer of the
+  template. So if a template is used that includes diffs, it will need to run
+  some expensive diffing operation, wikis with less resources can use a
+  template that doesn't include diffs and avoid that overhead.
+* 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]]