libgit2/rugged — pull request #172 by arthurschreiber (2013-03-20 22:59:48+00:00)
Title: Start implementing an FFI based backend

Heya,

I started working on an FFI based backend for Rugged, and this is how I've come so far in the last few hours. Before I continue putting more time into this, I wanted to open this PR to get some feedback on the general viability of an FFI based Rugged backend.

So far, what works is:
* Opening repos.
* `Rugged::Repository`: `#bare?`, `#exists?`, `#merge_base`, `#path`, `#workdir`, `#workdir=`, ...
* `Tag.each`, `Branch.each`, `Reference.each`, `Reference.lookup`, ...

Why I think maintaining a FFI based backend might be worthwhile:

* I find it much easier to iterate on API changes when you don't have to recompile the C binaries all the time. Also, having the whole extension written in Ruby might make it easier for new contributors and help with maintainability in the long-term.
* Performance on Rubinius and JRuby should be significantly better with FFI, and only marginally slower with MRI. Take this with a grain of salt, as I have not run any benchmarks yet to verify this. Also, as I don't think we'll throw away the binary extension, that will still be available to go full-speed on MRI.
* We can play around with new functionality in Ruby-Land, and then port them over to the C extension as soon as we have a nice API fleshed out.

Disadvantages would be that the C extension and the FFI version would have to be kept in sync.

I've seen that there was a previous ticket for this, #12, but was it was not followed up.

So, @brianmario and @vmg, what do you think?

(Also, maybe @tenderlove could throw in his 2 cents, because once upon a time there was also a FFI version of Nokogiri, which was killed of some time ago.)