9 files changed, 81 insertions, 19 deletions
diff --git a/doc/todo/Commit_emails:_ones_own_changes.mdwn b/doc/todo/Commit_emails:_ones_own_changes.mdwn
index d577c454f..862a85071 100644
--- a/doc/todo/Commit_emails:_ones_own_changes.mdwn
+++ b/doc/todo/Commit_emails:_ones_own_changes.mdwn
@@ -4,3 +4,6 @@ What's the rationale behind excluding ones own changes from the commit emails se
 > Well, commit mails are intended to keep you informed of changes in the
 > wiki, and I assumed you'd know about changes you made yourself.
 > --[[Joey]]
+
+> [[done]] -- commit mails removed; recentchanges feeds can be configured
+> for whatever you like.
diff --git a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
index 70970c6cc..dc456bbbf 100644
--- a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
+++ b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
@@ -3,4 +3,8 @@ user to add a page to their subscribed list while editing.  This would prove
 particularly useful for [[todo]] and [bug](bugs) items, to allow users to receive
 notifications for activity on their reports.
 
---[[JoshTriplett]]
-\ No newline at end of file
+--[[JoshTriplett]]
+
+I went and removed commit notification mails entirely, the idea is that you
+subscribe using the [[RecentChanges]] rss feed, and filter it on your end.
+Good enough? --[[Joey]]
diff --git a/doc/todo/aggregate_to_internal_pages.mdwn b/doc/todo/aggregate_to_internal_pages.mdwn
new file mode 100644
index 000000000..a4164fa25
--- /dev/null
+++ b/doc/todo/aggregate_to_internal_pages.mdwn
@@ -0,0 +1,5 @@
+The new internal page feature is designed for something like
+[[plugins/aggregate]].
+
+How to transition to it though? inlines of aggregated content would need to
+change their pagespecs to use `internal()`.
diff --git a/doc/todo/bzr.mdwn b/doc/todo/bzr.mdwn
index dbe35245c..51ae08146 100644
--- a/doc/todo/bzr.mdwn
+++ b/doc/todo/bzr.mdwn
@@ -4,6 +4,8 @@ rcs_commit was only changed to work around bzr's lack of a switch to set the
 username). bzr_log could probably be written better by someone better at perl,
 and rcs_getctime and rcs_notify aren't written at all. --[[bma]]
 
+(rcs_notify is not needed in this branch --[[Joey]])
+
     #!/usr/bin/perl
     
     use warnings;
@@ -183,4 +185,8 @@ and rcs_getctime and rcs_notify aren't written at all. --[[bma]]
 
 >>> It's new (in fact I'm not even sure that it made it in to 0.90, it might be in 0.91 due
 >>> in a couple of weeks.
->>> I was just noting it for a future enhancement. --[[JamesWestby]]
-\ No newline at end of file
+>>> I was just noting it for a future enhancement. --[[JamesWestby]]
+
+> I've just posted another patch with support for bzr, including support for 
+> --author and a testsuite to git://git.samba.org/jelmer/ikiwiki.git. I hadn't 
+> seen this page earlier.  --[[jelmer]]
diff --git a/doc/todo/httpauth_example.mdwn b/doc/todo/httpauth_example.mdwn
index f67f67371..0c6268aa1 100644
--- a/doc/todo/httpauth_example.mdwn
+++ b/doc/todo/httpauth_example.mdwn
@@ -3,3 +3,6 @@ authentication (perhaps as a [[tip|tips]]), showing how to authenticate the
 user for edits without requiring authentication for the entire wiki. (Ideally,
 recentchanges should work without authentication as well, even though it goes
 through the CGI.) --[[JoshTriplett]]
+
+> (Now that recentchanges is a static page, it auths the same as other wiki
+> pages.) --[[Joey]]
diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn
index e5de93521..608c7d681 100644
--- a/doc/todo/mercurial.mdwn
+++ b/doc/todo/mercurial.mdwn
@@ -1,6 +1,6 @@
 * Need to get post commit hook working (or an example of how to use it.)
   * See below. --[[bma]]
-* rcs_notify is not implemented
+* rcs_notify is not implemented (not needed in this branch --[[Joey]])
 * Is the code sufficiently robust? It just warns when mercurial fails.
 * When rcs_commit is called with a $user that is an openid, it will be
   passed through to mercurial -u. Will mercurial choke on this?
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index 4714a7a09..4bbda6565 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -44,7 +44,6 @@ Remaining TODOs:
     just for this bit of functionality?
   * Debian news file.
   * ikiwiki news file.
-  * Are commit emails still working?
 
 --[[tschwinge]]
 
diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn
index 0d702975f..89dbb04a2 100644
--- a/doc/todo/plugin.mdwn
+++ b/doc/todo/plugin.mdwn
@@ -6,20 +6,6 @@ Suggestions of ideas for plugins:
 > web-server-specific code to list all users, and openid can't feasibly do so
 > at all. --[[JoshTriplett]]
 
-* Support [[RecentChanges]] as a regular page containing a plugin that
-  updates each time there is a change, and statically builds the recent
-  changes list. (Would this be too expensive/inflexible? There might be
-  other ways to do it as a plugin, like making all links to RecentChanges
-  link to the cgi and have the cgi render it on demand.) 
-
-  Or using an iframe
-  to inline the cgi, although firefox seems to render that nastily with
-  nested scroll bars. :-(
-> Or just link to the equivalent in the version control system, if available;
-> gitweb's shortlog or summary view would work nicely as a
-> RecentChanges. --[[JoshTriplett]]
->>Why not fork the process?  We wouldn't have to wait around for a response since we would assume the recent changes page was being generated correctly.
-
 * It would be nice to be able to have a button to show "Differences" (or 
   "Show Diff") when editing a page. Is that an option that can be enabled?
   Using a plugin?
@@ -58,4 +44,4 @@ Suggestions of ideas for plugins:
 
 * As I couldn't find another place to ask, I'll try here. I would like to install some contributed plugins, but can not find anywhere to downlod them.
 
-  > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
-\ No newline at end of file
+  > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn
index d46c0d9a8..91128a860 100644
--- a/doc/todo/recentchanges.mdwn
+++ b/doc/todo/recentchanges.mdwn
@@ -86,3 +86,59 @@ 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.
+* 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 :-)