Open colstrom opened 9 years ago
thanks for flagging @colstrom . I added Ruby 2.2 support back in December an shipped a new release after not having had much time to work on the binding during 2014. It's glue between libzmq, czmq and Ruby via the MRI C extension APIs, so there's no FFI here.
As a first step, mind if I take a look at the API diffs between 2.x and 3.x first, then propose some extensions here, with a preference for ones that don't require modification (just additions) to the existing binding. That way we can release small changes for testing and feedback and maintain backwards compat as much as possible for existing users.
Alongside that, documentation needs some love too. And the security features (curve etc.), but I think it's a smaller error surface to handle them after API differences, OR consider security API additions as part of the czmq 2.x to 3.x upgrade.
Thoughts?
Sounds like a sane plan. A 10km view of the changes looks something like this:
It looks like zauth
, zbeacon
, zmonitor
, zproxy
, and zthread
were merged into zactor
. Since those usually got bundled anyways, that's a cleaner expression of intent for a lot of cases. They haven't been removed, though they are deprecated. That should make the transition somewhat easier.
zctx
and zsocket
were deprecated in favour of the new context-less zsock
, which is a nice improvement from a Ruby perspective (contexts always felt like C-isms seeping into Ruby). Along with this is deprecation of zsockopt
in favour of zsock_option
meant to play nice with zsock
.
zmutex
is deprecated now, I assume since it was primarily useful with the also-deprecated zthread
.
There are a few new items, zgossip
intends to address service-discovery problems, and looks useful in propagating configuration state changes as well.
The release notes mention a zrex
class for regular expressions? I have no idea what the intended use case is for that. Seems a bit out-of-scope for ZMQ's problem domain, but I haven't looked at it closely, so I could be a completely sensible use and I may just be talking out my ass.
I can look at cooking up some example docs, and I'll take a skim over the existing documentation to see where it needs the most love. Is there a preference for more implementation-focused (RDoc/YARD-style) or more example-driven with documentation of why user X might care about the functionality they're reading about? I guess I'm trying to identify the audience of the missing docs.
As for the security API additions, they don't seem tightly coupled with 3.x (they seem to be carried forward from 2.x). Important, but might be easier to implement without the API shifting underneath them.
Sounds good. Thanks for the detailed layout :-)
@colstrom I don't know the status of this, but if you're still looking for support, you might wanna take a look at CZTop. It supports zactor, zbeacon, zauth, zmonitor, zproxy through nice Ruby classes, and also CURVE.
@paddor I'll give that a spin, thanks!
I'm curious what the status of CZMQ 3.x support is in rbczmq. I'm interested in working with some of the classes introduced in 3.x (specifically zactor and zgossip). If support is non-trivial to add (I haven't done much with FFI, so I'd rather not assume anything about complexity), is there anywhere that I could focus my time to assist?
On a related tangent, it looks like ffi-rzmq has gone into maintenance-only mode (within the last week or so) in favour of this project. It looks like rbczmq is the left as the main library for developing (C)ZMQ-based applications in Ruby. Exciting! ^_^