From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-12-12T00:03:10+09:00
Subject: Re: Standardizing FFI based wrappers

Luc Heinrich wrote:
> - 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."

I agree with ffi/ path prefix. I agree with FFI:: prefix since there 
will already exist conflicts (built-in readline's "Readline" for example).

It will also be very nice to know they'll be prefixed with ffi/ and 
FFI:: in all cases.

> - 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 Lavena agreed: "Yeah, first layer of implementation and then 
> abstraction (Rubify)"
> Nit Khair 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)."

I agree with making them thin and am neutral on the "one repo" thing. We 
could certainly use the ruby-ffi project for that purpose, if storing 
them in a common repo was desirable.

> - 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.

I like ffi- prefix for all "simple" ffi wrapper gems.

- Charlie