|
5 years ago | |
---|---|---|
html | 6 years ago | |
libevent-2.0.22-stable | 6 years ago | |
server | 5 years ago | |
.hgignore | 5 years ago | |
README-OSX.md | 5 years ago | |
README.md | 6 years ago |
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.
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
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 127.0.0.1:4223 and a "security-token" that must be given in each function call to authenticate you as the valid user.
visit that address (normally http://127.0.0.1:4223/) 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!
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
Windows build:
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
Adapt the "p≡p Transport API", when it is final. (either manually or by code generator, if ready)