forked from monkey/monkey
-
Notifications
You must be signed in to change notification settings - Fork 0
/
roadmap_v1.4.txt
72 lines (51 loc) · 2.84 KB
/
roadmap_v1.4.txt
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Ideas and roadmap for Monkey v1.4
=================================
This is just a draft of ideas to implement in the development phase of
Monkey v1.4.
Core
------------
[+] declarations cleanup: all specific global structures and variables must be
prefixed with 'mk_'. We should move the code to use typedef structs to drop
long references, e.g:
struct client_session -> mk_client_session_t
struct session_request -> mk_session_request_t
[+] configure script/plugins: the configure script must be able to link a specific
plugin with a fixed path, and not only perform lookups in the plugins/ directory,
something like:
./configure --include-plugin=/path/to/plugin_source
Internal API
------------
[+] Mapping URIs to plugins: right now every plugin decides if it will work or not
an incoming connection, the optimal solution would be to decide in the virtual
host configuration through a regex or similar who should handle what.
Plugin API
------------
[+] session request + plugin data: some plugins requires to associate specific data
to a session_request. The current solution is to let the plugin handle it own
list through pthread keys which is too dirty and redundant solution across the
other plugins.
the solution proposed is an API function to link specific plugin data or context
to the request in question. It requires session_request modification for it purpose:
void mk_api->data_set(struct session_request *sr,
void *data,
int (*cleanup_callback) (struct session_request *sr));
void *mk_api->data_get(struct session_request *sr);
so inside a plugin, some data can be associated easily and when the core decides
to finish the work of that specific session, it should invoke the cleanup_callback()
so the plugin can release any resources associated.
[+] Kernel modules style to register callbacks: would be great to use a static structure
to define the callback functions that a plugin exposes to the core. Right now
everything is done through fixed named functions like _mkp_...().
The Linux modules uses a static struct for that purpose and looks more elegant.
[+] Streams: implement a streams mechanism to hook different sources of data and stream
them out to the client. Some streams to support should be:
- function: be able to define a function who provide a stream based in some
computed data, e.g: gzip, video encoding frames, etc.
- file descriptors: this include sockets, pipes, files, everything associated to
a fd.
Plugins
-----------
[+] gzip compression: easy to do but would be good to implement this over a 'stream' like
mechanism to avoid blocking for large data processing.
[+] proxy reverse: proxy back connections for HTTP, HTTPS and Websockets
[+] SPDY support.