Merge #55: Add doc/ folder, split up readme and add more usage documentation

1a3dc8d Add documentation about interface definitions (Russell Yanofsky)
5539208 Split up README.md (Russell Yanofsky)

Pull request description:

Top commit has no ACKs.

Tree-SHA512: 3df1e93a2df96d9ebd806828d61dac801b696a846f5b7abc14f9713e6279b35cb19ddb6c7033ea4584203663eb248f26a591d2b4df04cc205f676b42487aa68e

Author: ryanofsky

README.md

@@ -1,62 +1,8 @@
 # libmultiprocess
 
-## Summary
+`libmultiprocess` is a C++ library and code generator making it easy to call functions and reference objects in different processes.
 
-C++ library and code generator making it easy to call functions and reference objects in different processes.
+For more information see the [usage instructions](doc/usage.md), [installation instructions](doc/install.md), or [design documentation](doc/design.md).
 
-## Description
-
-Given an interface description of an object with one or more methods, libmultiprocess generates:
-
-* A C++ `ProxyClient` class with an implementation of each interface method that sends a request over a socket, waits for a response, and returns the result.
-* A C++ `ProxyServer` class that listens for requests over a socket and calls a wrapped C++ object implementating the same interface to actually execute the requests.
-
-The function call ⇆ request translation supports input and output arguments, standard types like `unique_ptr`, `vector`, `map`, and `optional`, and bidirectional calls between processes through interface pointer and `std::function` arguments.
-
-If the wrapped C++ object inherits from an abstract base class declaring virtual methods, the generated `ProxyClient` objects can inherit from the same class, allowing interprocess calls to replace local calls without changes to existing code.
-
-There is also optional support for thread mapping, so each thread making interprocess calls can have a dedicated thread processing requests from it, and callbacks from processing threads are executed on corresponding request threads (so recursive mutexes and thread names function as expected in callbacks).
-
-### What is `kj`?
-
-KJ is a concurrency framework [bundled with
-capnproto](https://capnproto.org/cxxrpc.html#kj-concurrency-framework); it is used as a
-basis in this library to construct the event-loop necessary to service IPC requests.
-
-## Example
-
-A simple interface description can be found at [test/mp/test/foo.capnp](test/mp/test/foo.capnp), implementation in [test/mp/test/foo.h](test/mp/test/foo.h), and usage in [test/mp/test/test.cpp](test/mp/test/test.cpp).
-
-A more complete example can be found in [example](example/) and run with:
-
-```sh
-make -C build example
-build/example/mpexample
-```
-
-## Future directions
-
-_libmultiprocess_ uses the [Cap'n Proto](https://capnproto.org) interface description language and protocol, but it could be extended or changed to use a different IDL/protocol like [gRPC](https://grpc.io). The nice thing about _Cap'n Proto_ compared to _gRPC_ and most other lower level protocols is that it allows interface pointers (_Services_ in gRPC parlance) to be passed as method arguments and return values, so object references and bidirectional requests work out of the box. Supporting a lower-level protocol would require writing adding maps and tracking code to proxy objects.
-
-_libmultiprocess_ is currently compatible with sandboxing but could add platform-specific sandboxing support or integration with a sandboxing library like [SAPI](https://github.com/google/sandboxed-api).
-
-## Installation
-
-Installation currently requires Cap'n Proto:
-
-```sh
-apt install libcapnp-dev capnproto
-brew install capnp
-dnf install capnproto
-```
-
-Installation steps are:
-
-```sh
-mkdir build
-cd build
-cmake ..
-make
-make check # Optionally build and run tests
-make install
-```
+If you have any questions, comments, or feedback, please submit an [issue](https://github.com/chaincodelabs/libmultiprocess/issues/new).
+Duplicate issues are perfectly fine and all discussion about the project is welcome, since there isn't another discussion forum currently.

doc/design.md

@@ -0,0 +1,30 @@
+# libmultiprocess Design
+
+Given an interface description of an object with one or more methods, libmultiprocess generates:
+
+* A C++ `ProxyClient` class with an implementation of each interface method that sends a request over a socket, waits for a response, and returns the result.
+* A C++ `ProxyServer` class that listens for requests over a socket and calls a wrapped C++ object implementating the same interface to actually execute the requests.
+
+The function call ⇆ request translation supports input and output arguments, standard types like `unique_ptr`, `vector`, `map`, and `optional`, and bidirectional calls between processes through interface pointer and `std::function` arguments.
+
+If the wrapped C++ object inherits from an abstract base class declaring virtual methods, the generated `ProxyClient` objects can inherit from the same class, allowing interprocess calls to replace local calls without changes to existing code.
+
+There is also optional support for thread mapping, so each thread making interprocess calls can have a dedicated thread processing requests from it, and callbacks from processing threads are executed on corresponding request threads (so recursive mutexes and thread names function as expected in callbacks).
+
+## Interface descriptions
+
+As explained in the [usage](usage.md) document, interface descriptions need to be consumed both by the _libmultiprocess_ code generator, and by C++ code that calls and implements the interfaces. The C++ code only needs to know about C++ arguments and return types, while the code generator only needs to know about capnp arguments and return types, but both need to know class and method names, so the corresponding `.h` and `.capnp` source files contain some of the same information, and have to be kept in sync manually when methods or parameters change. Despite the redundancy, reconciling the interface definitions is designed to be _straightforward_ and _safe_. _Straightforward_ because there is no need to write manual serialization code or use awkward intermediate types like [`UniValue`](https://github.com/bitcoin/bitcoin/blob/master/src/univalue/include/univalue.h) instead of native types. _Safe_ because if there are any inconsistencies between API and data definitions (even minor ones like using a narrow int data type for a wider int API input), there are errors at build time instead of errors or bugs at runtime.
+
+In the future, it would be possible to combine API and data definitions together using [C++ attributes](https://en.cppreference.com/w/cpp/language/attributes). To do this we would add attributes to the API definition files, and then generate the data definitions from the API definitions and attributes. I didn't take this approach mostly because it would be extra work, but also because until c++ standardizes reflection, this would require either hooking into compiler APIs like https://github.com/RosettaCommons/binder, or parsing c++ code manually like http://www.swig.org/.
+
+## What is `kj`?
+
+KJ is a concurrency framework [bundled with
+capnproto](https://capnproto.org/cxxrpc.html#kj-concurrency-framework); it is used as a
+basis in this library to construct the event-loop necessary to service IPC requests.
+
+## Future directions
+
+_libmultiprocess_ uses the [Cap'n Proto](https://capnproto.org) interface description language and protocol, but it could be extended or changed to use a different IDL/protocol like [gRPC](https://grpc.io). The nice thing about _Cap'n Proto_ compared to _gRPC_ and most other lower level protocols is that it allows interface pointers (_Services_ in gRPC parlance) to be passed as method arguments and return values, so object references and bidirectional requests work out of the box. Supporting a lower-level protocol would require writing adding maps and tracking code to proxy objects.
+
+_libmultiprocess_ is currently compatible with sandboxing but could add platform-specific sandboxing support or integration with a sandboxing library like [SAPI](https://github.com/google/sandboxed-api).

doc/install.md

@@ -0,0 +1,20 @@
+# libmultiprocess Installation
+
+Installation currently requires Cap'n Proto:
+
+```sh
+apt install libcapnp-dev capnproto
+brew install capnp
+dnf install capnproto
+```
+
+Installation steps are:
+
+```sh
+mkdir build
+cd build
+cmake ..
+make
+make check # Optionally build and run tests
+make install
+```

doc/usage.md

@@ -0,0 +1,24 @@
+# libmultiprocess Usage
+
+## Overview
+
+_libmultiprocess_ is a library and code generator that allows calling C++ class interfaces across different processes. For an interface to be available from other processses, it needs two definitions:
+
+- An **API definition** declaring how the interface is called. Included examples: [calculator.h](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/calculator.h), [printer.h](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/printer.h), [init.h](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/init.h). Bitcoin examples: [node.h](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/interfaces/node.h), [wallet.h](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/interfaces/wallet.h), [echo.h](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/interfaces/echo.h), [init.h](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/interfaces/init.h).
+
+- A **data definition** declaring how interface calls get sent across the wire. Included examples: [calculator.capnp](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/calculator.capnp), [printer.capnp](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/printer.capnp), [init.capnp](https://github.com/chaincodelabs/libmultiprocess/blob/master/example/init.capnp). Bitcoin examples: [node.capnp](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/ipc/capnp/node.capnp), [wallet.capnp](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/ipc/capnp/wallet.capnp), [echo.capnp](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/ipc/capnp/echo.capnp), [init.capnp](https://github.com/ryanofsky/bitcoin/blob/ipc-export/src/ipc/capnp/init.capnp).
+
+The `*.capnp` data definition files are consumed by the _libmultiprocess_ code generator and each `X.capnp` file generates `X.capnp.c++`, `X.capnp.h`, `X.capnp.proxy-client.c++`, `X.capnp.proxy-server.c++`, `X.capnp.proxy-types.c++`, `X.capnp.proxy-types.h`, and `X.capnp.proxy.h` output files. The generated files include `mp::ProxyClient<Interface>` and `mp::ProxyServer<Interface>` class specializations for all the interfaces in the `.capnp` files. These allow methods on C++ objects in one process to be called from other processes over IPC sockets.
+
+The `ProxyServer` objects help translate IPC requests from a socket to method calls on a local object. The `ProxyServer` objects are just used internally by the `mp::ServeStream(loop, socket, wrapped_object)` and `mp::ListenConnections(loop, socket, wrapped_object)` functions, and aren't exposed externally. The `ProxyClient` classes are exposed, and returned from the `mp::ConnectStream(loop, socket)` function and meant to be used directly. The classes implement methods described in `.capnp` definitions, and whenever any method is called, a request with the method arguments is sent over the associated IPC connection, and the corresponding `wrapped_object` method on the other end of the connection is called, with the `ProxyClient` method blocking until it returns and forwarding back any return value to the `ProxyClient` method caller.
+
+## Example
+
+A simple interface description can be found at [test/mp/test/foo.capnp](test/mp/test/foo.capnp), implementation in [test/mp/test/foo.h](test/mp/test/foo.h), and usage in [test/mp/test/test.cpp](test/mp/test/test.cpp).
+
+A more complete example can be found in [example](example/) and run with:
+
+```sh
+make -C build example
+build/example/mpexample
+```