> 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