kore

An easy to use, scalable and secure web application framework for writing web APIs in C.
Commits | Files | Refs | README | LICENSE | git clone https://git.kore.io/kore.git

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)