Hi Mahadev,

Open sourcing the Ruby bindings is definitely the plan.

The current code requires patches to zookeeper.c and zk_hashtable.c
to work around some sticky parts of MRI Ruby's threading model.

I spent some time trying to put all of the Ruby-specific stuff into
a Ruby C extension and keep the ZK code clean, but it looked like it
would involve maintaining a callback dispatch and return table and
other complexities that weren't reasonable for my application.  I
ended up just hacking the threading workarounds into the ZK API code,
which is obviously suboptimal.

I will add a configure option and #ifdefs to protect the standard
build from ruby.h dependencies, e.g.:


...but it will still be a bit messy.  If the interest level makes
it worthwhile to take on the complexity of bringing the Ruby stuff
into the official ZK tree, that's great.  If not, we can include
the diff (and/or a patched ZK C API tree??) in the ruby-zookeeper
gem distribution (it will be AL2.0 too).


Spurious bug report aside, the last few days have been productive.
All API functions are now implemented except ACL get/set, and only
a few remaining bugs:

  - threading issue in async create of an existing path on MRI
  - threading issue in async get of a non-existent path on MRI
  - intermittent (but frequent) context mangling on JRuby

I also want to bake a few of the ZK recipes into the Ruby libs,
but that should be straightforward (thanks to the great docs) :)

The code is in a private github repo presently, but if anyone
wants to look at it in its pre-beta state, let me know and we'll
open it up.


On Sun, Dec 20, 2009 at 08:45:13PM -0800, Mahadev Konar wrote:
> Hi Andrew,
>  Great to see ruby bindings for zookeeper. Would you be contributing it back
> to the zookeeper source tree? I am sure lots of folks would be interested in
> it. Please post to the list if you have any questions regarding the api or
> questions regarding how to contribute code back to the source tree.
> Thanks
> mahadev


Reply via email to