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