]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/todo.mdwn
web commit by http://joey.kitenet.net/: poll vote (It's too slow!)
[ikiwiki.git] / doc / todo.mdwn
index 00fcc0ce3885acba56238fcf8a092e3b472fbf43..001828b44acce7d79156f374a91f0d708934a155 100644 (file)
@@ -1,121 +1,6 @@
-## online page editing
+Welcome to ikiwiki's todo list. Link items to [[todo/done]] when done.
 
-* Eventually, might want page deletion.
-* Eventually, might want file upload.
+Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
 
-## recentchanges
-
-* Should support RSS for notification of new and changed pages. 
-
-  This can be a static rss file that is generated when the moo
-is built. (As long as all changes to all pages is ok.)
-
-* Should support mail notification of new and changed pages.
-
-  Hmm, should be easy to implement this.. it runs as a svn post-coommit hook
-  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
-filename extension. So for ".mdwn" files, it would send the content through
-linkify, markdown, and finalize, while for ".wiki" files it might send it
-through just a wiki formatter and finalize.
-
-This would allow not only supporting more types of markup, but changing
-what style of [[WikiLink]]s are supported, maybe some people want to add
-[[CamelCase]] for example, or don't like the [[SubPage/LinkingRules]].
-
-The finalize step is where the page gets all the pretty junk around the
-edges, so that clearly needs to be pluggable too.
-
-There also needs to be a step before finalize, where stuff like lists of pages
-that linked back to it could be added to the page. However, doing linkbacks
-also needs to tie into the main logic, to determine what pages need to be
-renered, so maybe that won't be a plugin.
-
-## revisit case
-
-Being case insensative is handy, but it does make the [[BackLinks]] a bit
-ugly compared to other links. It should be possible to support pagenames
-that have uppercase, while still allowing them to be linked to using any
-case.
-
-## html
-
-Make the html valid. Add css and prettify. Make RecentChanges use table for formatting, and images to indicate web vs svn commits and to link to diffs.
-
-All of this should be doable w/o touching a single line of code, just editing the [[templates]] BTW.
-
-## sigs
-
-Need a way to sign name in page that's easier to type than "--\[[Joey]]"
-and that includes the date.
-
-What syntax do other wikis use for this? I'm considering "\[[--]]" (with
-spaces removed) as it has a nice nmemonic.
-
-OTOH, adding additional syntax for this would be counter to one of the
-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 more than 100
-
-Possibly add "next 100" link to it, but OTOH, you can just use svn log if
-you need that data..
-
-## 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]]
+[[inline pages="todo/* and !todo/done and !link(todo/done) and !*/Discussion"
+actions=yes rootpage="todo" show=0]]