search

datrs / hypercore

Secure, distributed, append-only log
https://docs.rs/hypercore
Apache License 2.0
333 stars 37 forks source link

[WIP] 🙋FFI bindings #39

Closed luizirber closed 1 year ago

luizirber commented 6 years ago

(I'm opening this PR quite early to get more feedback and fix it)

Checklist

Context

As discussed in https://github.com/datrs/hypercore/issues/36, this sets up the FFI infrastructure with cbindgen. It is using the build.rs way, but many projects define a Makefile or some other external way to generate the bindings via the cbindgen command line. The reason is that expanding macros might take some time (I even disabled it for now), and this ends up being executed every time the crate is built (but the C header rarely changes).

I'm keeping the FFI module inside the hypercore repo. Some projects create another crate for the FFI, but I think this is easier to keep in sync.

I set up a Python project using it to help guide what APIs to expose thru the FFI. I was thinking about developing this by:

There is only one function for now (and it's not even very useful), but it already works to create a feed on the Python side

Semver Changes

No API changes on the Rust side.

luizirber commented 6 years ago

And with the Android bindings by @bltavares I think we have a good way to drive the 'Implementing the Rust FFI function' step, because we need to agree on what's useful for both Python and Java/Kotlin =]

luizirber commented 6 years ago

Hmm, turns out #![forbid(unsafe_code)] will be an issue for FFI. While it's mostly avoidable, there are things that need unsafe (like freeing memory with Box::from_raw).

The solution for now was to remove the crate-level attribute and put it on every mod line in lib.rs, which is a bit ugly and a lot of repetition...

yoshuawuyts commented 6 years ago

@luizirber o/ have you had the time to look at this more? Is there any way I could help to unblock you?

luizirber commented 6 years ago

Hi @yoshuawuyts! I wasn't sure how to start the hypercore-py API (what to expose and test there to guide the FFI bindings here). At first I was thinking about using the tests here as templates, but maybe following the original API is a better idea?

yoshuawuyts commented 6 years ago

At first I was thinking about using the tests here as templates, but maybe following the original API is a better idea?

Yeah, that sounds very reasonable! I'm not sure how far we could take this entirely because it makes use of some class overloading, and inherits from an emitter -- but trying to approximate it seems very reasonable!