README.md
author Roker <roker@pep-project.org>
Mon, 08 Aug 2016 18:59:02 +0200
branchno_SessionID_in_API
changeset 79 635220441345
parent 2 499d5f21aac8
child 159 e24a112bf6a2
permissions -rw-r--r--
close branche before merging
     1  1. Dependencies
     2 =================
     3 
     4 Debian
     5 ------
     6 * g++ 4.8 or 4.9
     7 * GNU make
     8 * libboost-filesystem-dev
     9 * p≡p Engine
    10   (which needs gpgme-thread, a patched libetpan, libboost-system-dev)
    11 
    12 It comes with libevent 2.20, that needs GNU autohell to build. :-/
    13 Maybe Debian Jessie's version 2.0 also works well, I never tried.
    14 
    15 
    16  2. Build
    17 ==========
    18 
    19 * build p≡p Engine
    20 
    21 * first build libevent, see libevent-2.0.22-stable/README
    22   (a user-install in $HOME/local/ is fine)
    23 
    24 * edit the library and include paths server/Makefile so p≡p & libevent will
    25   be found
    26 
    27 * run "make" in the server/ path
    28 
    29 
    30  3. Running
    31 ============
    32 
    33 * run ./mt-server
    34 
    35 * visit http://127.0.0.1:4223/ in your javascript-enabled web browser to see
    36   the test JavaScript client
    37 
    38 * call some functions ("version()" or "get_gpg_path()" should work just fine)
    39 
    40 
    41  4. Extending / Customizing
    42 ============================
    43 
    44 * The 'FunctionMap function' in mt-server.cc defines which functions are
    45   callable via the JSON-RPC interface. The existing entries show the syntax
    46   of that map.
    47 
    48 * At the moment only functions with a non-void return type ere supported.
    49   It is possible to extend the FunctionMap to support also void-returning
    50   functions if desired, but it would require more template specializations
    51   in function_map.hh etc. The alternative is a helper function that calls
    52   the void function and just returns a dummy value.
    53 
    54 * The current implementation supports input and output parameters, no "inout".
    55 
    56 * For each type there must exist specializations of the template classes
    57   "In" (for input parameters) and "Out" (for output parameters).
    58   The linker will tell you, which specializations are needed.  ;-)
    59 
    60 * The specializations for "generic types" are in function_map.cc
    61 
    62 * The specializations for "p≡p-specific types" are in pep-types.cc
    63 
    64 
    65  5. TODO
    66 =========
    67 
    68 * Add unit tests (I'd suggest GoogleTest/gtest? Any complaints?)
    69 
    70 * Fix the bugs that are found by the Unit tests, if any.
    71 
    72 * Let's generate all the tedious boiler plate code
    73     * the content of pep-types.cc
    74     * perhaps the FunctionMap 'function' in mt-server.cc
    75     * perhaps the JavaScript side of the HTML test page to ensure to be
    76       consistent with the server side in pep-types.cc
    77 
    78 * Adapt the "p≡p Transport API", when it is final.
    79   (either manually or by code generator, if ready)