[zeromq-dev] a more modern, Java-idiomatic jzmq/jeromq API

John Watson jkwatson at gmail.com
Tue Feb 5 16:44:39 CET 2013


I'd love to see what you've put together so far.

If it's in github, can you point me at it?  And, yes, let's chat.  Are you
available on the irc channel? If so, let's coordinate off-list a time to
chat about this.

John



On Tue, Feb 5, 2013 at 6:53 AM, Trevor Bernard <trevor.bernard at gmail.com>wrote:

> Awesome work John! I didn't realize you had a pull request in flight.
>
> We should have a chit chat at some point; I've also been working on a
> wrapper library on top of jzmq that has similar ideas.
>
> -Trev
>
> On Mon, Feb 4, 2013 at 11:31 PM, John Watson <jkwatson at gmail.com> wrote:
> > 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
> > messaging needs.
> >
> > John
> >
> > 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.
> >>>
> >>> -Trev
> >>>
> >>> 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
> >>> > the
> >>> > guide.  Initially I was quite turned off by the java APIs, which is
> why
> >>> > I
> >>> > want to make them more idiomatic.
> >>> >
> >>> > Anyone else using the java APIs (either jzmq or jeromq) who can
> provide
> >>> > me
> >>> > pain points from in the trenches will definitely help with the API
> >>> > design.
> >>> >
> >>> > My plan is to do this incrementally.  First, I'll work on
> "modernizing"
> >>> > the
> >>> > existing API (get rid of int flags, use Collections instead of
> arrays,
> >>> > make
> >>> > it more OO, etc), then, once I have a better handle on the bigger
> >>> > picture
> >>> > (and have studied CZMQ), I'll start layering higher level
> abstractions
> >>> > on
> >>> > top.
> >>> >
> >>> > If anyone has suggestions or ideas, please let me know.  You can also
> >>> > follow
> >>> > along on my progress in my jeromq fork on github.  I'm jkwatson over
> >>> > there.
> >>> >
> >>> > 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
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >>
> >
> >
> > _______________________________________________
> > 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
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130205/556ce64d/attachment.html>


More information about the zeromq-dev mailing list