]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/todo/be_more_selective_about_running_hooks.mdwn
response
[ikiwiki.git] / doc / todo / be_more_selective_about_running_hooks.mdwn
index b57bd5c7208ad8008c22475a9d11f6f9a706444a..4296477121b1aefaffb6cb44fb848cc7e45d56ca 100644 (file)
@@ -6,6 +6,12 @@ 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]]
+
 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,6 +25,30 @@ 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.
+>>
+>> --[[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]]