> My advice is to work in small cycles and using real code, e.g. the
> Guide samples, as your target.

We use 0MQ internally for as our IPC mechanism. I'll likely first
fulfil our needs and use-cases first before targeting the guide.

> CZMQ is of course for C; what is IMO a valuable aim is that we share
> common abstractions across high-level bindings. What we learn in one
> place, we can then apply to another. We've been collecting these in
> http://www.zeromq.org/topics:binding-abstractions.

I try to maintain the same the same vocabulary and the high level
constructs as there are now. Like John, I want it to be more Java
idiomatic code. My goal is to take advantage of the compiler and make
composeable/correct building blocks. Also another big goal is to more
easily/automatically manage the underlying ZMQ resources.

One big theme you'll notice in what I'm writing is that everything is
managed and you have to explicitly define the contract of the Socket
through the use of the builder pattern. I try to enforce only setting
valid socket parameters for a particular type of Socket. Eg. subscribe
and unsubscribe are only useful to ZMQ_SUB, etc.

Here is a gist of setting up a PULL socket:
https://gist.github.com/trevorbernard/4716646

Since this is a wrapper around JZMQ, it provides a nice little
playground to experiment with new ideas without affecting current
users of JZMQ. If you find certain ideas work well, you can port them
into the jzmq. Also, you could port jeromq as a backend as well.

-Trev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to