57 lines
2.2 KiB
Markdown
57 lines
2.2 KiB
Markdown
ikiwiki should support [[writing plugins in other languages|plugins/write/external]]
|
|
|
|
> [[done]] !!
|
|
|
|
While it should be possible to call ikiwiki from C, doing the callbacks in C is
|
|
probably hard. And accessing perl at all from C is ugly. It also doesn't
|
|
make it very easy to write plugins in an interpreted language, since that
|
|
would mean linking perl and eg, python in one binary. (Been there, done
|
|
that, never again.)
|
|
|
|
Instead, I'm considering using XML RPC to let ikiwiki communicate with a
|
|
child process that it can spawn. The child could then be any program,
|
|
written in any language. It could talk XML RPC via stdio. (This assumes
|
|
that most languages allow easily serialising XML::RPC calls and responses
|
|
to a file descriptor. Some XML RPC implementations may be hardcoded to use
|
|
http..) For ease of implementation, each rpc request sent via stio should
|
|
end with a newline, and begin with "<?xml ..>".
|
|
|
|
Here's how it would basically look, not showing the actual XML RPC used to
|
|
pass values.
|
|
|
|
-> call import
|
|
<- call hook type => preprocess, id => foo, call => plugin_preprocess
|
|
-> result 1
|
|
<- result 1
|
|
|
|
-> call plugin_preprocess page => bar
|
|
<- call getconfig url
|
|
-> result "http://example.com", ...
|
|
<- call debug "foo"
|
|
-> result 1
|
|
<- result done "my return value"
|
|
|
|
From ikiwiki's POV:
|
|
|
|
* ikiwiki always initiates each conversation with a command
|
|
* After sending a command, ikiwiki reads commands, dispatches them, and
|
|
returns the results, in a loop, until it gets a result for the command it
|
|
called.
|
|
|
|
From the plugin's POV:
|
|
|
|
* It's probably sitting in an XML::RPC loop.
|
|
* Get a command from ikiwiki.
|
|
* Dispatch the command to the appropriate function.
|
|
* The function can use XML::RPC to communicate with ikiwiki to get things
|
|
like config values; and to call ikiwiki functions.
|
|
* Send the function's return value back to ikiwiki.
|
|
|
|
Simple enough, really. ikiwiki would need to add accessor functions for
|
|
all important variables, such as "getconfig" and "setconfig". It would
|
|
probably be easiest for ikiwiki to dispatch a command by just evaling
|
|
IkiWiki::$command.
|
|
|
|
Plugin programs could be dropped into /usr/share/ikiwiki/plugins/, and
|
|
load_plugin() would just open2 the plugin program and call import.
|