simplify/optimize c interface
Opened this issue · 5 comments
craff commented
- a lot of functions that can not block should probably not release the runtime system (like embed_socket or get_file_descr)
- a lot of functions could be tagged @@noalloc if raising the exception was done on OCaml side (like get_file_descr).
Do we want to provide the apriori fastest possible binding (as long as they remain safe and simple) ?
anmonteiro commented
Do we want to provide the apriori fastest possible binding (as long as they remain safe and simple) ?
I think you touch on very interesting points. IMO this should definitely be a goal of the project.
Some more thoughts:
- ocaml-ssl has been around a long time
- Its APIs have mostly been added as needed, or at least that's my impression
- some APIs ended up being a bit inconsistent with others
- there's quite a bit of API functionality missing (e.g. compare to Rust's openssl-sys https://github.com/sfackler/rust-openssl/tree/master/openssl-sys/src)
I think it'd be a great idea to start some work on ocaml-ssl to:
- unify the APIs into a set of safe, fast, consistent and correct bindings
- expand the API surface area (expose some more useful openssl functions, e.g. the ones in libcrypto)
Your suggestions make sense. In order to facilitate review, I'd err on the side of minimal changes per PR, so that they're easier to review. Thanks for your interest.
craff commented
How fine grain the PRs ?
- one PR per function
- one PR for @@noalloc, one for removing useless runtime_release, one for each group of related features added
- another way for grouping
anmonteiro commented
I'd err on the side of 1 PR per "separate theme":
- 1 PR for all the functions that don't block so we can stop releasing the runtime lock
- 1 PR for the noalloc functionality so we can reason about that specific change only
- What's grouping?
craff commented
I meant that you might have another Idea for grouping changes together that the 2 I propose.