aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/be_more_selective_about_running_hooks.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/be_more_selective_about_running_hooks.mdwn')
-rw-r--r--doc/todo/be_more_selective_about_running_hooks.mdwn68
1 files changed, 68 insertions, 0 deletions
diff --git a/doc/todo/be_more_selective_about_running_hooks.mdwn b/doc/todo/be_more_selective_about_running_hooks.mdwn
new file mode 100644
index 000000000..70a1cb7a2
--- /dev/null
+++ b/doc/todo/be_more_selective_about_running_hooks.mdwn
@@ -0,0 +1,68 @@
+[[!template id=gitbranch branch=chrismgray/exclusive-hooks author="[[chrismgray]]"]]
+
+Sometimes plugins register a function with `hook`, but they only want
+the function called with the content that they know how to deal with.
+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.
+
+> 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
+things down.
+
+Thus, I propose that there be a new optional parameter to `hook` that
+tells it that the function should only be called for files whose type
+is the same as the id of the plugin calling `hook`. I have called
+this parameter `exclusive` in my branch, but this might not be the
+best name.
+
+[[!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.
+>
+> --[[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.
+>>
+>> --[[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]]