Add a method in the C bindings to replace the websocket API

[tomaka]

If you want to embed Parity in a binary, there should be some interface in the bindings in order to use the websocket capabilities of Parity without having to open a dummy TCP connection.

[tomaka]

The problem I've encountered while trying to work on this is that the threading model of our json_rpc crate (and, to be fair, of the client in general) is very blurry to me. I can write the C bindings, but I'd need some help when it comes to the Rust code.

[niklasad1]

@tomaka

Before digging down into this, let's just verify that I understand this correctly you are saying that we should introduce some kind of mechanism to subscribe to WebSocket events instead of polling via a separate connection?

If that is correct, I guess the easiest is just to add a callback to start_parity which should be invoked on every event?

[tomaka]

The root of the problem (the reason for this change) is that right now you can only perform synchronous RPC requests: https://github.com/paritytech/parity-ethereum/blob/aafe527d4a876ff57a04841aa1a2262e146fa2b9/parity-clib/parity.h#L91-L92

That means that you cannot subscribe to events (call eth_subscribe then wait). Only the WebSockets entry point does that.

we should introduce some kind of mechanism to subscribe to WebSocket events instead of polling via a separate connection?

Yes.

I guess the easiest is just to add a callback to start_parity which should be invoked on every event?

And yes.

Of course the problem is not modifying the C bindings, it's modifying the Rust code for the callback to be called.

[tomusdrw]

@niklasad1 I can help you out with all RPC related stuff. To support Pub-Sub model you will need to provide session object here:
https://github.com/paritytech/parity-ethereum/blob/aafe527d4a876ff57a04841aa1a2262e146fa2b9/parity/run.rs#L842

And that session object requires a transmitting end of a channel that will get stringified notifications.

@tomaka Why not change the entire model of the bindings to be callback based instead of blocking?

[tomaka]

Why not change the entire model of the bindings to be callback based instead of blocking?

Well, that's what I think we should do.

[niklasad1]

@tomaka shall we keep the synchronous interface and provide rpc_sync and rpc_async or is it enough with an async interface?

[tomaka]

I guess async is enough.