## 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.
## 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.
-## docs
+ 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.
-Need to turn [[usage]] into a man page.
-this wiki too. Can markdown generate a man page somehow?
+ I think that the new globlist() function should do everything you need.
+ Adding a field to the prefs page will be trivial --[[Joey]]
+
+ 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
also needs to tie into the main logic, to determine what pages need to be
renered, so maybe that won't be a plugin.
+## blogging and rss
+
+The wiki should emit rss feeds for pages. The simple case is a regular
+page (done). The complex case is a blog composed of multiple pages.
+
+### multi-page blog
+
+This also takes care of the feature of wanting to make a wiki page
+comprised of several sub-pages that can be independantly edited. Add a
+token that can be embedded into a page and that specifies a [[GlobList]] of
+pages. Now when any page matching the globs changes, this page must be
+updated too.
+
+For the html rendering, just embed the most recently created N pages in the
+[[GlobList]], with the title of each being a link to the individual page,
+plus a link to an additional page that lists all the titles of every
+matching page in creation order (archives). Plus at the bottom a small web
+form that prompts for a title and allows creating a new page for a new blog
+post.
+
+For the rss rendering, generate a proper weblog of the same pages.
+Of course for permalinks use the links to the subpages.
+
+Note that this allows for weblogs with different sections, etc.
+
+Requirements:
+
+* Need to keep track of creation dates of pages in the index file.
+* Need to keep track of the globlists in the index file.
+* Need to pick a good token and note that the token will need to be passed
+ multiple parameters. Possibly something like this:
+
+ [[inline pages="myblog/*" show="30"]]
+
## revisit case
Being case insensative is handy, but it does make the [[BackLinks]] a bit
## html
-Make the html valid. Add css.
+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
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..
-## setup classes
+## 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.
+* page name substring search
+* full text (use third-party tools?)
-## base wiki
+## lists
-Need a toned down version of this wiki with a basic frontpage, sandbox and
-docs to use as a seed for new wikis.
+* list of all missing pages
+* list of all pages or some kind of page map (probably covered by the rss
+ feeds stuff above)
-## search
+These could be their own static pages updated when other pages are updated.
+Perhaps this ties in with the pluggable renderers stuff.
-* 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?
+
+## basewiki underlay
+
+Rather than copy the basewiki around everywhere, it should be configured to
+underlay the main srcdir, and pages be rendered from there if not in the
+srcdir. This would allow upgrades to add/edit pages in the basewiki.
+
+Impementaion will be slightly tricky since currently ikiwiki is hardcoded
+in many places to look in srcdir for pages. Also, there are possible
+security attacks in the vein of providing a file ikiwiki would normally
+skip in the srcdir, and tricking it to processing this file instead of the
+one from the underlaydir.
+
+There are also difficulties related to removing files from the srcdir, and
+exposing ones from the underlaydir. Will need to make sure that the mtime
+for the source file is zeroed when the page is removed, and that it then
+finds the underlay file and treats it as newer.
+
+## 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]]
sipb-www / ikiwiki.git / blobdiff