Expose a C interface

[rask]

Not sure if this has been asked about before, finding anything with just "C" in the query is a mess and "interface" "ABI" and so on return irrelevant stuff for me.

Rust supports exporting a C-ABI interface for dynamic libraries and building C-ABI libraries (DLL/SO). Would it be in scope for this project to provide the C-interface by itself, or would the maintainers prefer that being developed as a separate crate?

With a C interface we could use this crate inside other languages that support C-ABI, for instance C (duh), Python, PHP, Ruby, and many more, often via regular FFI tooling.

[tomaka]

I wouldn't say a C interface is out of scope, but it would be quite complicated to do.

Rust-libp2p is designed to be very generic, and that obviously causes some problems when it comes to designing a C API.

I can see two kinds of approaches:

Approach 1

The C API could give the possibility to its users to customize how rust-libp2p works. You could plug your own protocols or transports.

Unfortunately this looks rather complicated to do to me. One would need to pass a lot of callbacks around, and also worry about the lifetime of these callbacks. Nothing undoable, but it might end up being very error-prone to use from a C perspective.

Approach 2

The C API could be based upon a certain predefined list of protocols and transports. For example, we could imagine C functions such as start_kademlia_query which assume that Kademlia is available.

Of course you could disable Kademlia at initialization if you wanted to, but the point is that it wouldn't be possible to add your own custom protocols or transports.

If we go for approach 2, then considering how opinionated that list can be I'd maybe rather go for a separate crate.

[jrhea]

@rask i started work on a C interface to rust-libp2p last year as a stopgap solution for an eth2 client i was working on. it's nowhere near prod ready and it is my first experience with rust; however, i am able to use it for various side projects and nethermind is currently using it for their eth2 client (i owe them some updates though). the approach i took was similar to @tomaka's approach 2. it is opinionated about discovery, transports, etc ... but it might be a decent starting point. You are welcome to fork it or contribute to it if it is useful:

https://github.com/prrkl/mothra