Make ffi public? about rust-rocksdb HOT 7 CLOSED

I'm in favor of exposing rocksdb::ffi as public. Historically I've hit a number of annoying issues with wrapper libraries that excessively hide functionality. I'm also in favor of adding an unsafe, well-documented no-copy iterator method for those who would benefit from the use case.

from rust-rocksdb.

Surely the solution here is simply to import the sys crate directly, if you want the ffi functionality? That sounds much cleaner, to me.

from rust-rocksdb.

I'd like to make sure I'm always using a compatible -sys crate with the rocksdb crate. Problem is that if I use the -sys crate directly i'd have to specify a direct dependency to it in the Cargo.toml for my project so have to make sure it's a compatible version when updating rocksdb (which is a minor annoyance).

from rust-rocksdb.

Hmm, fair point, I suppose... is this convention though? I don't see any other crates doing this.

from rust-rocksdb.

There are a couple cases where this is done, nix comes to mind. We use it at work for re-exporting types. E.g. the core of our utility libraries are codegen'd from protobufs or whatever, and the easiest way to stay in sync is have the utility libraries re-export the codegen'd functionality.

from rust-rocksdb.

I feel the real issue here is that this crate doesn't expose sufficient functionality. I think in the past few months we have been making good strides towards improving the situation (eg. #209, #212, #238, #240, #246, #248, #253, #263). I actually like the pressure of GitHub issues stating that functionality is not accessible as a motivating force to improve this crate. Exposing the FFI might mean we will get fewer of those issues (or PRs) since a workaround exists.

I propose we close this issue and continue working toward exposing more functionality.

/cc @aleksuss @vitvakatu

from rust-rocksdb.

There haven't been any objections to my proposal. I'm going to close and we can revisit if someone feels otherwise.

from rust-rocksdb.