Greetings,
Back in november, when FFI 0.1.1 was released, there was a beginning
of an interesting discussion about “standardizing” the way FFI based
wrappers should be named, organized and packaged, in order to create a
clean and useful (and hopefully growing) FFI “ecosystem” (yeah, I
know, but I couldn’t find a better word for it). Some good suggestions
were made but I don’t think anything was really settled. I think it
would be good to continue this discussion now and decide on a set of
guidelines, maybe illustrated by a sample wrapper.
Here’s what I could gather so far:
-
About organization:
Sean O’Halpin wondered “if it would be useful to have these FFI-
enabled libs under an ffi/ namespace, e.g. you’d require ‘ffi/ncurses’
and possibly include FFI::NCurses. We could put shared structs,
constants, etc. under ffi/include.” -
About packaging:
Sean O’Halpin thinks “it’s better to provide a thin bridge and then
abstract on top of that. […] Thin wrapper in a single gem. Any
abstractions should be separate gems.”
Luis L. agreed: “Yeah, first layer of implementation and then
abstraction (Rubify)”
Nit K. then suggested that “some of these conversions/wrappers
would be “approved” and sort of become a standard, so we don’t have a
plethora of them. Then they could be placed in one repo (after some
sort of review).” -
About naming:
Tom Enebo suggested “just naming them the library name, as in
libncurses, libtommath, whatever.”
Sean O’Halpin thinks that it’s “a little *nix-centric”.
I would personnally suggest to name them “ffi-{LIBNAME}”, like ffi-
zlib or ffi-ncurses, etc, this makes it obvious what it is and makes
it easier to search for all ffi based wrappers in rubygems repositories.
If you have something to add or any comment on all this, please speak
out