* `lib_stdlib`: basic extended OCaml stdlib and generic data structures
* `lib_data_encoding`: almost independant 'Data_encoding'
* `lib_error_monad`: almost independant 'Error_monad'
* `lib_stdlib_lwt`: extended Lwt library
* `lib_crypto`: all the crypto stuff (hashing, signing, cryptobox).
* `lib_base`:
- basic type definitions (Block_header, Operation, ...)
- a module `TzPervasives` to bind them all and to be the
single module opened everywhere.
In the process, I splitted `Tezos_data` and `Hash` in multiple
submodules, thus removing a lot of `-open`.
The following two modules may not have found their place yet:
- Base58 (currently in `lib_crypto`)
- Cli_entries (currently in `lib_stdlib_lwt`)
The new version of ocplib-resto :
- uses jbuilder ;
- is functorized over `Json_encoding` rather than `Json_repr` ;
- handles query parameters ;
- handles HTTP methods (GET, POST, DELETE, PUT, PATCH) ;
- replaces `custom_service` by a more generic trailer argument ;
- replaces generic answer `(code, body)` by a more ad-hoc sum type
(allowing distinct encoding for success and error) ;
- includes a minimal HTTP-server based on Cohttp
(includings CORS and media type negotiation).
- adds a function `Directory.transparent_lookup` to lookup/call
a service handler without serializing the various parameters
(path, query, request body).
As a first consequences in Tezos, this patch allows binary
communication between the client and the node.
This patch tries to be minimal inside the tezos source code and
therefore it introduces a minimal compatibility layer in
`RPC.ml`. This code should be removed as soon as possible.
This is a dirty and non-optimized backend, it is still faster than the
current git backend.
Main drawbacks:
- the leveldb binding is non-coopertive, the node will
block while committing a block to the disk ;
- the leveldb use 'string' while internally we use 'cstruct',
this implies a lot of time-consuming 'memcpy'.
The `branch` of the operation contains enough information to induce
the `net_id`, and the code of the validator/prevalidator is now mature
enough to efficiently determine the `net_id` of an incoming operation.
