[zeromq-dev] a more modern, Java-idiomatic jzmq/jeromq API
jkwatson at gmail.com
Tue Feb 5 04:31:20 CET 2013
There is a pull request in effect on the jeromq project. I'm continually
adding to it. The more I work on things, the more it feels like we need
some higher-level abstractions.
A couple of ideas:
1) Maybe we should ask the context to createDealer() (for example) and
have it return a Dealer object, with only the functionality that makes
sense for Dealer sockets. [repeat for other socket types]
2) So far, the jzmq project & the corresponding code in jeromq have been
striving to be pretty close analogues to the CZMQ code. I don't believe
that this is really the best way to approach things. I propose that we
design a high-level, modern, java-centric API that makes it really easy for
developers to get in the game. Certainly there is much to be learned from
the way that CZMQ was built and the facilities that it provides, but, at
its core, it is a c API, not a java API.
As I'm mostly a zeromq newb, it's going to take me a while to sort out what
will really be the best way to go. Those who have used zeromq via java can
definitely provide a lot of value here. When you implemented a real-life
project that used zeromq, what wrappers, higher-level abstractions did you
create? That's the kind of stuff that will be invaluable.
My goal, stated in a Pieter-style "one-liner": Make the java API attractive
enough that Bob Lee will want to use it internally at Square for all their
ps. Bob Lee, if you're on this list, and Square is already using zeromq,
your experiences will definitely be invaluable! :)
On Sun, Feb 3, 2013 at 12:29 PM, John Watson <jkwatson at gmail.com> wrote:
> Sounds great, Trev. As soon as I have something roughed out, I'll send a
> pull request to the main jeromq project for perusal.
> On Sun, Feb 3, 2013 at 11:55 AM, Trevor Bernard <trevor.bernard at gmail.com>wrote:
>> I am in favour of this idea as well. Also, releasing stable builds to
>> central would be a major plus. I'd be more than happy to donate my
>> time for this effort.
>> On Sun, Feb 3, 2013 at 1:02 PM, John Watson <jkwatson at gmail.com> wrote:
>> > On Sun, Feb 3, 2013 at 4:57 AM, Pieter Hintjens <ph at imatix.com> wrote:
>> >> I'd encourage you to look at CZMQ and at least use some common
>> >> terminology, if you don't map to similar classes. The key features
>> >> which help a lot are:
>> >> * message = list of frames
>> >> * attached threads, connected by 'pipes'
>> >> * automatic closing of sockets when context is destroyed
>> >> * context-level linger option
>> >> I'm also thinking of writing a class to hide zmq_poll and do that more
>> >> neatly, e.g. manage tickless timers automatically.
>> > Excellent ideas. I'm pretty much a zeromq newb, still working through
>> > guide. Initially I was quite turned off by the java APIs, which is why
>> > want to make them more idiomatic.
>> > Anyone else using the java APIs (either jzmq or jeromq) who can provide
>> > pain points from in the trenches will definitely help with the API
>> > My plan is to do this incrementally. First, I'll work on "modernizing"
>> > existing API (get rid of int flags, use Collections instead of arrays,
>> > it more OO, etc), then, once I have a better handle on the bigger
>> > (and have studied CZMQ), I'll start layering higher level abstractions
>> > top.
>> > If anyone has suggestions or ideas, please let me know. You can also
>> > along on my progress in my jeromq fork on github. I'm jkwatson over
>> > Thanks,
>> > John
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev