Merge branch 'master' into fancypodcast

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

diff --git a/doc/todo/be_more_selective_about_running_hooks.mdwn b/doc/todo/be_more_selective_about_running_hooks.mdwn
index d9fefb9818c9e97506b57c32f25234b248731e02..70a1cb7a2ae6e946fa46c72d018fa0cdabbebea9 100644 (file)
--- a/doc/todo/be_more_selective_about_running_hooks.mdwn
+++ b/doc/todo/be_more_selective_about_running_hooks.mdwn
@@ -6,6 +6,17 @@ Normally, this means that they call `pagetype` first thing in the
 function, determine if they know how to deal with the content, and
 only do anything if they do.  
 
 function, determine if they know how to deal with the content, and
 only do anything if they do.  
 

+> So, I can't find any plugins shipped with ikiwiki that actually do that.
+> Scan hooks are only ever passed the content of actual wiki pages, and
+> so unless a scan hook cares whether a page is written in markdown or
+> something else, it has no reason to care what the pagetype is. (Same for
+> linkify.) --[[Joey]]
+
+>> My [[org-mode|todo/org_mode]] external plugin (which will never
+>> really make sense to include with ikiwiki I think) does this.  I
+>> think that most plugins defining alternate wiki syntaxes would as
+>> well. --[[chrismgray]]
+

 This is a bit wasteful in itself, but for external plugins, it's
 really bad.  For functions like `scan` and `linkify`, where the entire
 page is sent back and forth over `stdout` and `stdin`, it really slows
 This is a bit wasteful in itself, but for external plugins, it's
 really bad.  For functions like `scan` and `linkify`, where the entire
 page is sent back and forth over `stdout` and `stdin`, it really slows


@@ -19,10 +30,39 @@ best name.
 
 [[!tag patch]]
 
 
 [[!tag patch]]
 

-> It's an interesting idea, but it might be more useful if it was more generalized, say, by making it a filter, where the parameter is a regexp.
+> It's an interesting idea, but it might be more useful if it was more
+> generalized, say, by making it a filter, where the parameter is a regexp.

 > 
 > --[[KathrynAndersen]]
 
 > 
 > --[[KathrynAndersen]]
 

->> Would it make more sense as a pagespec?  That might be a bit more hard to implement, but would certainly fix the naming issue.
+>> Would it make more sense as a pagespec?  That might be a bit more hard
+>> to implement, but would certainly fix the naming issue.

 >>
 >> --[[chrismgray]]
 >>
 >> --[[chrismgray]]

+
+>>> Considering where it would be called, a pagespec might be overkill. --[[KathrynAndersen]]
+
+>>>> Pagespecs have some overhead themselves. Probably less than shipping
+>>>> the page content over stdio.
+>>>>
+>>>> Rather than putting filtering in the core of ikiwiki, I can think
+>>>> of two options. One is to make the main plugin a perl plugin, and
+>>>> have it call functions that are provided by another, external plugin.
+>>>> This is assuming you're using the other language because something
+>>>> is easy to do in it, not to avoid writing perl.
+>>>> 
+>>>> Or, the external plugin interface could provide a version of `hook()`
+>>>> that does not pass the content parameter, but saves a copy that
+>>>> the plugin could request with a later rpc call. Assuming that
+>>>> it's really the overhead of serializing the page content, that's
+>>>> the problem, and not just the general overhead of making rpc calls
+>>>> for every page.. --[[Joey]]
+
+>>>>> Since the argument to `hook` is optional, the pagespec is only
+>>>>> interpreted if it is given.  So there is no extra overhead
+>>>>> (beyond an unused `if` branch) in 99% of the cases.  
+>>>>>
+>>>>> Rewriting the external plugin's shim using Perl is a good idea,
+>>>>> and one that I wish I had thought of earlier.  On the other
+>>>>> hand, it doesn't set a great precedent about the usability of
+>>>>> external plugins. --[[chrismgray]]