p≡p JSON adapter
Go to file
Damiano Boppart b1d1238514 Move out configurable variables from Makefile to Makefile.conf. Add license information 2017-08-03 17:40:34 +02:00
html new version "(23) Engelskirchen": fix JSON-19. Support "Bool" and "Language" as separate data types in JavaScript. 2017-01-17 19:30:08 +01:00
libevent-2.0.22-stable Initial check-in / Erstlingseinfügung / inserire iniziale intenzionale / Первый чек-ин 2016-03-30 08:29:52 +02:00
server Move out configurable variables from Makefile to Makefile.conf. Add license information 2017-08-03 17:40:34 +02:00
.hgignore Update .hgignore, exclude all the libevent binaries 2017-03-20 18:03:52 +01:00
README-OSX.md Fix Makefile and update build instructions for macOS 2017-03-20 18:05:09 +01:00
README.md update README.md 2017-02-16 15:41:03 +01:00


  1. Dependencies =================


  • g++ 4.8 or 4.9
  • GNU make
  • libboost-filesystem-dev
  • p≡p Engine (which needs gpgme-thread, a patched libetpan, libboost-system-dev)

It comes with libevent 2.20, that needs GNU autohell to build. :-/ Maybe Debian Jessie's version 2.0 also works well, I never tried.

  1. Build ==========
  • build p≡p Engine

  • first build libevent, see libevent-2.0.22-stable/README (a user-install in $HOME/local/ is fine)

  • edit the library and include paths server/Makefile so p≡p & libevent will be found

  • run "make" in the server/ path

  1. Running ============
  • run ./pep-json-server

  • it creates a file, readable only by the current user, /tmp/pEp-json-token-${USER} that contains the address and port the JSON adapter is listening on, normally and a "security-token" that must be given in each function call to authenticate you as the valid user.

  • visit that address (normally in your javascript-enabled web browser to see the test JavaScript client

  • call some functions ("version()" or "get_gpg_path()" should work just fine), Don't forget to call them with the right security token!

  1. Extending / Customizing ============================
  • The 'FunctionMap function' in mt-server.cc defines which functions are callable via the JSON-RPC interface. The existing entries show the syntax of that map.

  • At the moment only functions with a non-void return type ere supported. It is possible to extend the FunctionMap to support also void-returning functions if desired, but it would require more template specializations in function_map.hh etc. The alternative is a helper function that calls the void function and just returns a dummy value.

  • The current implementation supports input and output parameters, no "inout".

  • For each type there must exist specializations of the template classes "In" (for input parameters) and "Out" (for output parameters). The linker will tell you, which specializations are needed. ;-)

  • The specializations for "generic types" are in function_map.cc

  • The specializations for "p≡p-specific types" are in pep-types.cc

  1. TODO =========
  • Windows build:

    • implement get_token_filename() for MS Windows (security-token.cc line 43
    • do the windows-specific stuff to build the software on Windows
  • Add unit tests (I'd suggest GoogleTest/gtest? Any complaints?)

  • Fix the bugs that are found by the Unit tests, if any.

  • Let's generate all the tedious boiler plate code

    • the content of pep-types.cc
    • perhaps the FunctionMap 'function' in mt-server.cc
    • perhaps the JavaScript side of the HTML test page to ensure to be consistent with the server side in pep-types.cc
  • Adapt the "p≡p Transport API", when it is final. (either manually or by code generator, if ready)