web commit by BrandenRobinson: Add brainstorming about email change notification.

[ikiwiki.git] / doc / todo.mdwn

diff --git a/doc/todo.mdwn b/doc/todo.mdwn
index dd69e21fb6cf95d8a4ca65a783b65d032440500a..6a14228fb0238f5d3b628deb5fa50eb2dea80846 100644 (file)
--- a/doc/todo.mdwn
+++ b/doc/todo.mdwn
@@ -19,10 +19,27 @@ is built. (As long as all changes to all pages is ok.)
   already, so just look at the userdb, svnlook at what's changed, and send
   mails to people who have subscribed.
 
-## docs
-
-Need to turn [[usage]] into a man page.
-this wiki too. Can markdown generate a man page somehow?
+  A few details:
+  1. [[Joey]] mentioned that being able to subscribe to globs as well as
+     explicitly named pages would be desirable.
+  2. I think that since we're using Perl on the backend, being able to
+     let users craft their own arbitrary regexes would be good.
+  3. Of course if you do that, you want to have form processing on the user
+     page that lets them tune it, and probably choose literal or glob by
+     default.
+
+  The first cut, I suppose, could use one sendmail process to batch-mail all
+  subscribers for a given page.  However, in the long run, I can see users
+  demanding a bit of feature creep:
+
+  4. Each user should be able to tune whether they see the actual diff parts or
+     not.
+  5. Each user should be able to set a maximum desired email size.
+  6. We might want to support a user-specified shibboleth string that will be
+     included in the email they receive so they can easily procmail the messages
+     into a folder.
+
+  --[[BrandenRobinson]]
 
 ## pluggable renderers
 
@@ -77,13 +94,15 @@ recentchanges that goes to the diff for any listed change.
 Possibly add "next 100" link to it, but OTOH, you can just use svn log if
 you need that data..
 
-## setup classes
+## base wiki
+
+Need a toned down version of this wiki with a basic frontpage, sandbox and
+docs to use as a seed for new wikis.
+
+## search
 
-The setup files should "use WikiWiki::Setup" and the like at the top, and
-indeed could just be one big use that passes all params to the module's
-importer. The module then handles running ikiwiki functions. This would
-allow for different types of setup files for more than just the one
-hardcoded thing there is now, and would probably be good for upgrades,
-incompatible changes, etc, too.
+* full text (use third-party tools?)
+* list of all missing pages
+* list of all pages or some kind of page map
 
 ## [[Bugs]]