capnp: Cap'n Proto for Haskell
This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.
A native Haskell implementation of the Cap'N Proto cerialization format and RPC protocol.
The library implements serialization and level 1 RPC.
The Capnp.Tutorial module is the best place to start reading; the reference documentation can seem bewildering without that context.
[Skip to Readme]
Properties
| Versions | 0.1.0.0, 0.2.0.0, 0.3.0.0, 0.4.0.0, 0.4.0.0, 0.5.0.0, 0.6.0.0, 0.6.0.1, 0.6.0.2, 0.6.0.3, 0.7.0.0, 0.8.0.0, 0.9.0.0, 0.10.0.0, 0.10.0.1, 0.11.0.0, 0.12.0.0, 0.12.1.0, 0.13.0.0, 0.14.0.0, 0.15.0.0, 0.16.0.0, 0.17.0.0, 0.18.0.0 |
|---|---|
| Change log | CHANGELOG.md |
| Dependencies | async (>=2.2.1 && <2.3), base (>=4.11 && <4.13), bytes (>=0.15.4 && <0.16), bytestring (>=0.10 && <0.11), capnp, containers (>=0.5.9 && <0.6), cpu (>=0.1.2 && <0.2), data-default (>=0.7.1 && <0.8), data-default-instances-vector (>=0.0.1 && <0.1), directory (>=1.3.0 && <1.4), exceptions (>=0.10.0 && <0.11), filepath (>=1.4.2 && <1.5), focus (>=1.0.1 && <1.1), hashable (>=1.2.7 && <1.3), list-t (>=1.0.2 && <1.1), mtl (>=2.2.2 && <2.3), network (>=2.8.0 && <2.9), network-simple (>=0.4 && <0.5), pretty-show (>=1.9.5 && <1.10), primitive (>=0.6.3 && <0.7), reinterpret-cast (>=0.1.0 && <0.2), safe-exceptions (>=0.1.7 && <0.2), stm (>=2.5.0 && <2.6), stm-containers (>=1.1.0 && <1.2), supervisors (>=0.2.0 && <0.3), text (>=1.2 && <2.0), transformers (>=0.5.2 && <0.6), vector (>=0.12.0 && <0.13), wl-pprint-text (>=1.2 && <1.3) [details] |
| License | MIT |
| Copyright | 2016-2018 haskell-capnp contributors (see CONTRIBUTORS file). |
| Author | Ian Denhardt |
| Maintainer | ian@zenhack.net |
| Category | Data, Serialization, Network, Rpc |
| Home page | https://github.com/zenhack/haskell-capnp |
| Bug tracker | https://github.com/zenhack/haskell-capnp/issues |
| Source repo | head: git clone https://github.com/zenhack/haskell-capnp.git -b master |
| Uploaded | by isd at 2019-01-27T14:27:49Z |
Modules
[Index] [Quick Jump]
- Capnp
- Capnp.Address
- Capnp.Basics
- Capnp.Bits
- Capnp.Classes
- Capnp.Convert
- Capnp.Errors
- Capnp.Gen
- Capnp.GenHelpers
- Capnp.IO
- Capnp.Message
- Capnp.Pointer
- Capnp.Rpc
- Capnp.TraversalLimit
- Capnp.Tutorial
- Capnp.Untyped
- Data
Downloads
- capnp-0.4.0.0.tar.gz [browse] (Cabal source package)
- Package description (as included in the package)
Maintainer's Corner
Package maintainers
For package maintainers and hackage trustees
Readme for capnp-0.4.0.0
[back to package description]
A Haskell library for the Cap'N Proto Cerialization and RPC protocol.
Getting Started
There is a module Capnp.Tutorial which contains an introduction
to the library; users are strongly encouraged to read this first, as
the reference documentation can be bewildering without that context.
Status
Serialization support works, with some limitations:
- Generated schema currently ignore type parameters (#29).
- We do not support define custom default values for fields of pointer type; see (#28).
- We currently do not correctly handle decoding lists of structs from non-composite lists (#27). This means that, contrary to the protocol evolution rules, it is not safe to change a field from type List(T) (where T is any non-struct type) to a list of a struct type.
Level 1 RPC support is implemented and usable, though there are a couple gaps in the API. It should be considered alpha quality for now. Specific things to be aware of:
- The implementation is not robust against resource exhaustion attacks; for now users are strongly discouraged from using it to do RPC with untrusted peers.
- While most of the machinery for it is in place, the API does not currently expose a way to do field projection on remote promises. As a consequence, actually pipelining method calls is not currently possible, so the library is currently best suited to environments which are already low-latency.
The API is considered unstable. It will likely see changes, for the sake of polish, consistency, etc. as well as to improve performance and accommodate more features as we add them.