On Fri, Sep 26, 2014 at 09:51:50AM +0200, Pieter Hintjens wrote:
> On Fri, Sep 26, 2014 at 3:10 AM, Goswin von Brederlow <goswin-...@web.de>
> wrote:
>
> > Pieter: Would it be possible to put all the examples of the guide into
> > a git project and have them included in the auto compile done for
> > every pull request?
>
> The examples are in a subdirectory of the Guide git project, and we
> could activate Travis CI on that, though with a lot of languages it's
> unclear how we'd proceed. For C and C++ sure.
>
> I'll get around to updating the Guide for V4 at some stage. I've been
> collecting a lot of the material on my blog already so it's not a huge
> job, just fiddly.
>
> I'm kind of waiting to release CZMQ v3 first so that the C examples
> can use that. I think it's time to start burying the old ZeroMQ API.
> This has been a long goal of mine, to raise the high level semantics
> and get that working among all languages.
>
> What is the general opinion about moving classes from CZMQ to libzmq?
> We're seeing a lot of projects wrapping CZMQ now. If we eventually
> merge the two projects, we get back to a single target for languages
> to bind to. This is already where JeroMQ/JZMQ got to as well (a single
> common high level API)
I love that things are no longer void * but have proper distinct
types. What I don't like is the double or tripple indirection the CZMQ
classes add. I prefer type safety over polymorphism there.
If the two get merged then why not merge the zsock class with the
libzqm socket structure. Use it as is for the zsock interface and cast
it to void * for the sake of the old API. A true merge and not just
layering the czmq API over the old one.
> This would be worth a ZeroMQ v5 version upgrade in my opinion. At the
> same time we can kill the deprecated CZMQ classes, review some of the
> cute details like reference counting in frames, and so on... it also
> means we can start to rewrite parts of libzmq itself using the CZMQ
> style and containers.
>
> Sorry, getting ahead of myself here.
>
> Problem: we have two separate C APIs which is confusing and harder to
> package/ship
>
> Solution: merge the CZMQ v3 classes into libzmq and deliver as a single
> package.
>
> Discussion: do this after both CZMQ v3 and ZeroMQ v4.1 are released,
> and stamp this with a V5 label. Leave the old ZeroMQ v2 and v3 APIs in
> there (forever as far as I'm concerned).
>
>
> -Pieter
I would like to have a stable libzmq v4.1 soon because we at Q-Leap
Networks want to use curve for authentication (requires zmq_msg_gets
from 4.1) soon and I would rather have a stable version in the
distribution than a git snapshot. Similary Debian Jessie would benefit
from a new stable libzmq.
I wouldn't feel comfortable in rushing a release with czmq merged into
libzmq. This sounds like a fairly large change with lots of breakage
till all the details are ironed out. Better to make what we have
stable and releasing it before radically changing the lib. My 2c.
MfG
Goswin
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
