commit ccd9e1046a8a4d757ac298559355905bee138d24
parent 6e4b403662dcaf2bcf062b9389d0d4c5c06ec7ce
Author: Joris Vink <joris@coders.se>
Date: Wed, 29 Jan 2014 23:00:43 +0100
Remove included docs, they are outdated.
Diffstat:
| docs/MODULES | | | 61 | ------------------------------------------------------------- |
| docs/TODO | | | 11 | ----------- |
| docs/scaling | | | 52 | ---------------------------------------------------- |
3 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/docs/MODULES b/docs/MODULES
@@ -1,61 +0,0 @@
-Page to function mapping
-========================
-In the configuration file you specify how pages on your site are
-mapped to what callback in your module.
-
-static /profile.html serve_profile
-
-The above example binds the callback serve_profile() to the profile.html page.
-Kore automatically calls this callback when the page is requested by a client.
-
-All callbacks must be based on this prototype:
- int callback(struct http_request *);
-
-Callback functions MUST return either KORE_RESULT_OK,
-KORE_RESULT_ERROR or KORE_RESULT_RETRY.
-
-KORE_RESULT_OK will cleanup the request and remove it.
-KORE_RESULT_ERROR will disconnect the client immediately after returning.
-KORE_RESULT_RETRY will reschedule the callback to be called again.
-
-Most of the times KORE_RESULT_ERROR or KORE_RESULT_OK should come from:
- int http_response(struct http_request *req,
- int status, u_int8_t *data, u_int32_t datalen);
-
-The http_response() function is used to queue up the HTTP response
-(including status code and content to be sent).
-
-If you wish to add headers to the response do so before calling http_response():
- void http_response_header_add(struct http_request *req,
- char *header, char *value);
-
-If your callback wants to use POST data, it should populate it first by calling:
- int http_populate_arguments(struct http_request *req);
-
-The returned value is the number of arguments available.
-After calling the populate function you can retrieve arguments by calling:
- int http_argument_lookup(struct http_request *req,
- const char *name, char **out);
-
-This will store the value of the requested argument in the out parameter.
-If http_argument_lookup() returns KORE_RESULT_ERROR out will be NULL.
-
-Please see the example/ folder for a good overview of a module.
-
-Static content
-==============
-Static content is included directly in the module.
-The example module shows how this is done.
-
-After adding each static component to the Makefile, it will convert it
-to a .c source file and export certain symbols that can be used by the module.
-
-Each component gets 3 symbols:
- static_[html|css]_<component_name> actual data.
- static_len_[html|css]_<component_name> length of the data.
- static_mtime_[html|css]_<component_name> last modified timestamp.
-
-API functions
-=============
- See includes/kore.h and includes/http.h for a definite overview.
-
diff --git a/docs/TODO b/docs/TODO
@@ -1,11 +0,0 @@
-Kore TODO list
-===============
-
-- Websocket support.
-- Better param syntax
-- Auxiliary library framework.
- - Provide more API functions for generic stuff such as
- session handler, page building, etc etc.
-- API to programmatically configure, start and stop Kore.
-- Find that one memory leak that's causing me agony beyond belief.
-- Get my hands on a 48 core server to test stuff on.
diff --git a/docs/scaling b/docs/scaling
@@ -1,52 +0,0 @@
-Scaling in Kore:
- - Badass mode
- - Minion mode
-
-Badass mode:
- - Receives connections from browsers
- - Selects available remote minion worker
- - Ties connection to worker and acts as a proxy in between
- - Persistent connections between minion worker processes
- - Pushes module and configuration changes to minions
-
- Starting Kore in badass mode, badass workers get <port>+<worker nr>:
-
- # ./kore -b 127.0.0.1:3350 -c /etc/kore.conf
-
-Minion mode:
- - ZERO configuration, minions get all required stuff from badass
- - Each worker connects to the main badass port announcing itself
- - Receives module
- - Receives page handlers
- - Receives ports for all badass workers
- - Connects to each worker, announcing itself
-
- - Receives all HTTP requests, parses and handles them
- - Responses go back to badass
- - kore_log() and access_log() go to badass (one log location)
-
-In badass mode, minions no longer need:
- - any configuration options.
- - CPU detection should happen via CLI or automatic
- Start a Kore process as a minion (and fetch everything from badass
- running on 127.0.0.1).
-
- # ./kore -m 127.0.0.1:3350 (-c 8 cpu count)
-
-Protocol between badass/minions:
- - Must be stream based (multiple different requests per single conn)
- - Badass assigns unique streamID per new external connection
- - The streamID is sent before each packet
- - Type is added as well:
- - 1 HTTP
- - 2 SPDY
- - 3 LOG
- - 4 ALOG
- - 5 MODUPDATE
- - 6 CONFIG
- - 7 PING
- - 8 FIN
- - Badass probably wants to buffer packets before sending them
- to the minion
- - Responses coming from minions are terminated by sending FIN.
- (at which point badass will start responding to client)
