aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/support_for_plugins_written_in_other_languages.mdwn
blob: 006b6fd5ea895be29fec48ec2bc2a248880906f7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
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.