capnproto-rust
                                
                                 capnproto-rust copied to clipboard
                                
                                    capnproto-rust copied to clipboard
                            
                            
                            
                        EzRpc equivalent?
I'm just looking at the examples for this library, and tbh the amount of boilerplate is kind of intimidating. All this flexibility (and performance?) is of course nice when you need it, but for getting started it'd be much nicer if you could just do
server = capnp.TwoPartyServer('*:60000', bootstrap=CalculatorImpl())
server.run_forever()
or
  capnp::EzRpcServer server(kj::heap<CalculatorImpl>(), argv[1]);
  auto& waitScope = server.getWaitScope();
  kj::NEVER_DONE.wait(waitScope);
instead of
    tokio::task::LocalSet::new().run_until(async move {
        let listener = tokio::net::TcpListener::bind(&addr).await?;
        let calc: calculator::Client = capnp_rpc::new_client(CalculatorImpl);
        loop {
            let (stream, _) = listener.accept().await?;
            stream.set_nodelay(true)?;
            let (reader, writer) = tokio_util::compat::TokioAsyncReadCompatExt::compat(stream).split();
            let network =
                twoparty::VatNetwork::new(reader, writer,
                                          rpc_twoparty_capnp::Side::Server, Default::default());
            let rpc_system = RpcSystem::new(Box::new(network), Some(calc.clone().client));
            tokio::task::spawn_local(Box::pin(rpc_system.map_err(|e| println!("error: {:?}", e)).map(|_| ())));
        }
    }).await
I recognize the skeleton of a classic accept loop, but what's inside is just letter soup to me. But no offense taken if the current system is judged by the maintainers to be the perfect level of control and abstraction.
Something like EzRpc would require us to commit to the I/O library (tokio, async-std, or whatever else), and I would prefer to avoid doing that in capnp-rpc. Maybe we could do it in a helper crate, or via feature flags?
I do suspect the current Rust top-level capnp-rpc API could be made a lot more understandable than it currently is, even without going so far as to provide an EzRpc-like interface.
If this library is not tied to a particular I/O library, would it be possible to make a server that just uses standard library blocking IO?
It seems unlikely to me that using blocking I/O from std could be made to work.