X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/a1a7019f276902c53aad2b2cb71e74f6e974fa05..773731743df52d2ef2d8ce93c095be981bb9bfc8:/doc/todo.mdwn

diff --git a/doc/todo.mdwn b/doc/todo.mdwn
index 68b1ccff5..39d4604d7 100644
--- a/doc/todo.mdwn
+++ b/doc/todo.mdwn
@@ -1,8 +1,5 @@
 ## online page editing
 
-* Missing support for preview.
-* Missing conflict detection, just overwrites changes and does not svn up
-  first..
 * Eventually, might want page deletion.
 * Eventually, might want file upload.
 
@@ -19,6 +16,34 @@ 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.
 
+  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.
+
+     Joey points out that this is actually a security hole, because Perl
+     regexes let you embed (arbitrary?) Perl expressions inside them.  Yuck!
+
+     It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --[[Joey]]
+
+  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
 
 I'm considering a configurable rendering pipeline for each supported
@@ -62,25 +87,33 @@ design goals for ikiwiki: keeping as much markup as possible out of the
 wiki and not adding nonstandard markup. And it's not significantly hard to
 type "--\[[Joey]]", and as to the date, we do have page history.
 
-## recentchanges links to commit diffs
-
-Would take a bit more viewcvs integration, let the be a "[diff]" link in
-recentchanges that goes to the diff for any listed change.
-
 ## recentchanges more than 100
 
 Possibly add "next 100" link to it, but OTOH, you can just use svn log if
 you need that data..
 
-## 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
 
 * full text (use third-party tools?)
 * list of all missing pages
 * list of all pages or some kind of page map
 
+## page indexes
+
+Might be nice to support automatically generating an index based on headers in a page, for long pages. The question is, how to turn on such an index?
+
+## page locking
+
+Some wikis will need the abiity to lock a page, or the whole wiki, so that only admins can edit them. Probably using the same globbing as for recentchanges mails to determine what to lock. 
+
+Probably it's ok if locking is only supported for web commits.
+
+## User settings page
+
+A cgi page to allow a user to log out and to edit their prefs, including password, email, and anything we add later (subscriptions, etc).
+
+## Logo
+
+ikiwiki needs a logo. I'm thinking something simple like the word "ikiwiki" with the first "k" backwards; drawn to show that it's "wiki" reflected.
+
 ## [[Bugs]]