README.md
author Roker <roker@pep-project.org>
Thu, 16 Feb 2017 15:41:03 +0100
changeset 159 e24a112bf6a2
parent 2 499d5f21aac8
child 231 cdafeb20364b
permissions -rw-r--r--
update README.md
     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 ./pep-json-server
    34 
    35 * it creates a file, readable only by the current user,
    36     /tmp/pEp-json-token-${USER}
    37   that contains the address and port the JSON adapter is listening on, normally 127.0.0.1:4223
    38   and a "security-token" that must be given in each function call to authenticate you as the valid user.
    39 
    40 * visit that address (normally http://127.0.0.1:4223/) in your javascript-enabled web browser to see
    41   the test JavaScript client
    42 
    43 * call some functions ("version()" or "get_gpg_path()" should work just fine),
    44   Don't forget to call them with the right security token!
    45 
    46 
    47  4. Extending / Customizing
    48 ============================
    49 
    50 * The 'FunctionMap function' in mt-server.cc defines which functions are
    51   callable via the JSON-RPC interface. The existing entries show the syntax
    52   of that map.
    53 
    54 * At the moment only functions with a non-void return type ere supported.
    55   It is possible to extend the FunctionMap to support also void-returning
    56   functions if desired, but it would require more template specializations
    57   in function_map.hh etc. The alternative is a helper function that calls
    58   the void function and just returns a dummy value.
    59 
    60 * The current implementation supports input and output parameters, no "inout".
    61 
    62 * For each type there must exist specializations of the template classes
    63   "In" (for input parameters) and "Out" (for output parameters).
    64   The linker will tell you, which specializations are needed.  ;-)
    65 
    66 * The specializations for "generic types" are in function_map.cc
    67 
    68 * The specializations for "p≡p-specific types" are in pep-types.cc
    69 
    70 
    71  5. TODO
    72 =========
    73 
    74 * Windows build:
    75    * implement get_token_filename() for MS Windows (security-token.cc line 43
    76    * do the windows-specific stuff to build the software on Windows
    77 
    78 * Add unit tests (I'd suggest GoogleTest/gtest? Any complaints?)
    79 
    80 * Fix the bugs that are found by the Unit tests, if any.
    81 
    82 * Let's generate all the tedious boiler plate code
    83     * the content of pep-types.cc
    84     * perhaps the FunctionMap 'function' in mt-server.cc
    85     * perhaps the JavaScript side of the HTML test page to ensure to be
    86       consistent with the server side in pep-types.cc
    87 
    88 * Adapt the "p≡p Transport API", when it is final.
    89   (either manually or by code generator, if ready)