]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/plugin.mdwn
remove clutter
[git.ikiwiki.info.git] / doc / todo / plugin.mdwn
index 4cbe256382e2ee626d03144e667eba46ff8bb50e..0f37d61908a35e8842754ff8d2b6e30e1e6b4bb3 100644 (file)
@@ -1,30 +1,40 @@
-A plugin system should ideally support things like:
+Suggestions of ideas for plugins:
 
-* [[todo/lists]] of pages, of mising pages / broken links, of registered users, etc
-* a [[todo/link_map]]
+* Support for restructured text (should be semi-easy to add basic support
+  now)
+* 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?
+* a [[link_map]]
+* [[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?
-* 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.)
-* etc
-* For another type of plugin, see [[todo/PluggableRenderers]]. 
+* Wiki stats, such as total number of links, most linked to pages (done)
 
-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.
+* 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.) 
 
-## preprocessor plugins
+  Or using an iframe
+  to inline the cgi, although firefox seems to render that nastily with
+  nested scroll bars. :-(
 
-done
+* 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]]
 
-## case study: Moin Moin plugins
+* interwiki links
 
-See <http://moinmoin.wikiwikiweb.de/MoinDev/PluginConcept>
+* random page (cgi plugin; how to link to it easily?)
 
-6 different types of plugins:
+* navigation or side bar plugin, would use a specific page as the side bar
+  and include it into the other pages as specified by the template. The
+  pagetemplate hook was added to allow for this.
 
-* *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]]).
+All the kinds of plugins that blogging software has is also a possibility:
+
+* Blog post calendar