]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/be_more_selective_about_running_hooks.mdwn
oh yes, good idea.
[git.ikiwiki.info.git] / doc / todo / be_more_selective_about_running_hooks.mdwn
1 [[!template  id=gitbranch branch=chrismgray/exclusive-hooks author="[[chrismgray]]"]]
3 Sometimes plugins register a function with `hook`, but they only want
4 the function called with the content that they know how to deal with.
5 Normally, this means that they call `pagetype` first thing in the
6 function, determine if they know how to deal with the content, and
7 only do anything if they do.  
9 > So, I can't find any plugins shipped with ikiwiki that actually do that.
10 > Scan hooks are only ever passed the content of actual wiki pages, and
11 > so unless a scan hook cares whether a page is written in markdown or
12 > something else, it has no reason to care what the pagetype is. (Same for
13 > linkify.) --[[Joey]]
15 >> My [[org-mode|todo/org_mode]] external plugin (which will never
16 >> really make sense to include with ikiwiki I think) does this.  I
17 >> think that most plugins defining alternate wiki syntaxes would as
18 >> well. --[[chrismgray]]
20 This is a bit wasteful in itself, but for external plugins, it's
21 really bad.  For functions like `scan` and `linkify`, where the entire
22 page is sent back and forth over `stdout` and `stdin`, it really slows
23 things down.  
25 Thus, I propose that there be a new optional parameter to `hook` that
26 tells it that the function should only be called for files whose type
27 is the same as the id of the plugin calling `hook`.  I have called
28 this parameter `exclusive` in my branch, but this might not be the
29 best name.
31 [[!tag patch]]
33 > It's an interesting idea, but it might be more useful if it was more
34 > generalized, say, by making it a filter, where the parameter is a regexp.
35
36 > --[[KathrynAndersen]]
38 >> Would it make more sense as a pagespec?  That might be a bit more hard
39 >> to implement, but would certainly fix the naming issue.
40 >>
41 >> --[[chrismgray]]
43 >>> Considering where it would be called, a pagespec might be overkill. --[[KathrynAndersen]]
45 >>>> Pagespecs have some overhead themselves. Probably less than shipping
46 >>>> the page content over stdio.
47 >>>>
48 >>>> Rather than putting filtering in the core of ikiwiki, I can think
49 >>>> of two options. One is to make the main plugin a perl plugin, and
50 >>>> have it call functions that are provided by another, external plugin.
51 >>>> This is assuming you're using the other language because something
52 >>>> is easy to do in it, not to avoid writing perl.
53 >>>> 
54 >>>> Or, the external plugin interface could provide a version of `hook()`
55 >>>> that does not pass the content parameter, but saves a copy that
56 >>>> the plugin could request with a later rpc call. Assuming that
57 >>>> it's really the overhead of serializing the page content, that's
58 >>>> the problem, and not just the general overhead of making rpc calls
59 >>>> for every page.. --[[Joey]]
61 >>>>> Since the argument to `hook` is optional, the pagespec is only
62 >>>>> interpreted if it is given.  So there is no extra overhead
63 >>>>> (beyond an unused `if` branch) in 99% of the cases.  
64 >>>>>
65 >>>>> Rewriting the external plugin's shim using Perl is a good idea,
66 >>>>> and one that I wish I had thought of earlier.  On the other
67 >>>>> hand, it doesn't set a great precedent about the usability of
68 >>>>> external plugins. --[[chrismgray]]