updates

[git.ikiwiki.info.git] / doc / todo / plugin.mdwn

diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn
index 1d49de66a19d78ac02e1c6f5550f16ded802d9b6..11886635073590e14090613cc79adfca92659b64 100644 (file)
--- a/doc/todo/plugin.mdwn
+++ b/doc/todo/plugin.mdwn
@@ -1,36 +1,36 @@
-For one type of plugin, see [[todo/PluggableRenderers]]. 
+Suggestions of ideas for plugins:

 
 

-A plugin system should ideally support things like:
+* list of registered users - tricky because it sorta calls for a way to rebuild the page when a new user is registered. Might be better as a cgi?
+* [[sigs]] ?

 
 

-* [[todo/lists]] of pages, of mising pages / broken links, of registered users, etc
-* a [[todo/link_map]]
-* [[todo/sigs]]
-* [[pageindexes]]
-* Wiki stats, such as the total number of pages, total number of links, most linked to pages, etc, etc.
-* wiki info page, giving the ikiwiki version etc
-* would it be useful to reimplement the hyperestradier search integration as a plugin?
-* Maybe it would be possible to make RecentChanges a regular wiki page, by making it a page that renders statically, but somehow runs the cgi at view time to dyamically render the changes? Then this could be a plugin too. How would this be accomplished in html though? Only way I know is via server side includes..
-* etc
+* 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.) 

 
 

-Another, separate plugin system that already (mostly) exists in ikiwiki is the RCS backend, which allows writing modules to drive other RCS systems than subversion.
+  Or using an iframe
+  to inline the cgi, although firefox seems to render that nastily with
+  nested scroll bars. :-(

 
 

-## preprocessor plugins
+* For PlaceWiki I want to be able to do some custom plugins, including one
+  that links together subpages about the same place created by different
+  users. This seems to call for a plugin that applies to every page w/o any
+  specific marker being used, and pre-or-post-processes the full page
+  content. It also needs to update pages when related pages are added,
+  so it needs to register dependencies pre-emptively between pages,
+  or something. It's possible that this is a special case of backlinks and
+  is best implemented by making backlinks a plugin somehow. --[[Joey]]

 
 

-Considering ikiwiki plugins, one idea I have is to make the [[PreProcessorDirective]]s be a plugin. A setting in the config file would enable various plusins, which are perl modules, that each provide one or more preprocessor directives. 
+* interwiki links

 
 

-Since preprocessing happens before htmlization but after a page is loaded and linkified, it should be possible to use it to create something like a link map or lists, or a page index. Page inlining and rss generation is already done via preprocessor directives and seems a natureal as a plugin too. 
+* random page (cgi plugin; how to link to it easily?)

 
 

-Note that things like a link map or a broken link list page would need to be updated whenever a set (or all) pages change; the %inlinepages hash already allows for pages to register this, although it might need to be renamed. 
+All the kinds of plugins that blogging software has is also a possibility:

 
 

-I need to look at the full range of things that other wikis use their plugin systems for, but preprocessor directives as plugins certianly seems useful, even if it's  not a complete solution.
+* Blog post calendar

 
 

-## case study: Moin Moin plugins
+* How about an event calendar. Events could be sub-pages with an embedded 
+ code to detail recurrance and/or event date/time

 
 

-See <http://moinmoin.wikiwikiweb.de/MoinDev/PluginConcept>
-
-6 different types of plugins:
-
-* *actions* are possibly out of scope for ikiwiki, this is probably what it uses for cgi script type stuff. Unless ikiwiki wants to allow pluggable CGI script stuff, it doesn't need these.
-* *parsers* and *formatters* are basically what I've been calling [[PluggableRenderers]]. MoinMoin separates these, so that a page is parsed to (presumbly) some intermediate form before being output as html or some other form. That's a nice separation, but what to do about things like markdown that are both a parser and a formatter?
-* *macros* and *processors* are analagous to preprocessor directives. A processor can operate on a large block of text though.
-* *themes* should be irrellevant (ikiwiki has [[templates]]).
+* Vote taking plugin. It would need to store its data in a file in .ikiwiki/