doc/todo/be_more_selective_about_running_hooks.mdwn

   1 [[!template  id=gitbranch branch=chrismgray/exclusive-hooks author="[[chrismgray]]"]]
   2
   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.
   8
   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]]
  14
  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]]
  19
  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.
  24
  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.
  30
  31 [[!tag patch]]
  32
  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]]
  37
  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]]
  42
  43 >>> Considering where it would be called, a pagespec might be overkill. --[[KathrynAndersen]]
  44
  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]]
  60
  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]]