capnweb 0.0.0-b2fcb34 → 0.0.0-c2bb17b

package/README.md

@@ -201,12 +201,12 @@ The following types can be passed over RPC (in arguments or return values), and
 * `Date`
 * `Uint8Array`
 * `Error` and its well-known subclasses
+* `ReadableStream` and `WritableStream`, with automatic flow control.
 
 The following types are not supported as of this writing, but may be added in the future:
 * `Map` and `Set`
 * `ArrayBuffer` and typed arrays other than `Uint8Array`
 * `RegExp`
-* `ReadableStream` and `WritableStream`, with automatic flow control.
 * `Headers`, `Request`, and `Response`
 
 The following are intentionally NOT supported:
@@ -305,6 +305,10 @@ The trick here is record-replay: On the calling side, Cap'n Web will invoke your
 
 Since all of the not-yet-determined values seen by the callback are represented as `RpcPromise`s, the callback's behavior is deterministic. Any actual computation (arithmetic, branching, etc.) can't possibly use these promises as (meaningful) inputs, so would logically produce the same results for every invocation of the callback. Any such computation will actually end up being performed on the sending side, just once, with the results being imbued into the recording.
 
+### Streaming with flow control
+
+You may pass a `ReadableStream` or `WritableStream` over RPC. When doing so, the RPC system automatically creates an equivalent stream at the other end and pumps bytes (or arbitrarily-typed chunks) across. This is done in such a way as to ensure the available bandwidth is fully utilized while minimizing buffer bloat, by observing the bandwidth-delay product and applying backpressure when too much is written. Multiple streams can be sent across the same connection -- they will be multiplexed appropriately, similar to HTTP/2 stream multiplexing.
+
 ### Cloudflare Workers RPC interoperability
 
 Cap'n Web works on any JavaScript platform. But, on Cloudflare Workers specifically, it's designed to play nicely with the [the built-in RPC system](https://blog.cloudflare.com/javascript-native-rpc/). The two have basically the same semantics, the only difference being that Workers RPC is a built-in API provided by the Workers Runtime, whereas Cap'n Web is implemented in pure JavaScript.
@@ -528,6 +532,14 @@ export default {
 }
 ```
 
+#### Compatibility with Workers' built-in RPC
+
+Cloudflare Workers has long featured [a built-in RPC system with semantics similar to Cap'n Web](https://developers.cloudflare.com/workers/runtime-apis/rpc/).
+
+Cap'n Web is designed to be compatible with Workers RPC, meaning you can pass Cap'n Web RPC stubs over Workers RPC and vice versa. The system will automatically wrap one stub type in the other and arrange to proxy calls.
+
+For best compatibility, make sure to set your [Workers compatibilty date](https://developers.cloudflare.com/workers/configuration/compatibility-dates/) to at least `2026-01-20`, or enable the [compatibility flag](https://developers.cloudflare.com/workers/configuration/compatibility-flags/) `rpc_params_dup_stubs`. (As of this writing, `2026-01-20` is in the future, so you will need to use the flag for now.)
+
 ### HTTP server on Node.js
 
 A server on Node.js is a bit more involved, due to the awkward handling of WebSockets in Node's HTTP library.
@@ -642,6 +654,10 @@ function newWebSocketRpcSession(
     : Disposable;
 ```
 
+### HTTP server using Hono
+
+If your app is built on [Hono](https://hono.dev/) (on any runtime it supports), check out [`@hono/capnweb`](https://github.com/honojs/middleware/tree/main/packages/capnweb).
+
 ### MessagePort
 
 Cap'n Web can also talk over MessagePorts. This can be used in a browser to talk to Web Workers, iframes, etc.