Such values are not allowed by the JSON spec. We match the behavior of
JSON.stringify in Firefox and Chrome.

fixes https://github.com/sandstorm-io/capnproto/issues/261

Fix some documentation typos.

Fix typo in documentation

Add TextCodec to expose an API for the schema's text format.

Spellcheck the styleguide

Typo found by @mquandalle

Mentioned three days ago, didn't want it to get forgotten

Fix typo in two party RPC docs

Make sure ArrayPtr<char> stringifies the same as ArrayPtr<const char> (without commas after each character)

Use ip4 sockets for wildcard on OpenBSD

Short-term fix for #220.

Fix typos.

Added method accept() to TwoPartyServer for servicing arbitrary AsyncIoStreams.

Increase arenaSpace to fix 32-bit builds.

Fix bug in JSON encoder that caused each byte of a UTF-8 sequence to be escaped as a separate character.

Added capnp::TwoPartyServer::accept(...) this method allows capnp::TwoPartyServer to service arbitrary kj::AsyncIOStream objects such as those representing two-way pipes (socketpairs).

The library allows for registering special handlers for specific types or fields. This is particluarly useful for overriding the way `Data` is encoded (since many approaches exist) or supporting encodings like EJSON or Q which extend JSON with special types encoded as objects with field names perfixed by dollar signs.

Not integrated into build system yet (but builds nicely with Ekam). I think this is going to need to be a separate library, e.g. libcapnp-json, because clearly a lot of Cap'n Proto users don't need it at all.

For the moment, this was written for use inside Sandstorm. There is no current need for a decoder, so I have not written that yet and have no immediate plans to do so. But it will be added before any official Cap'n Proto release, certainly. A simple recursive descent parser should be easy...