[nanomsg] Re: hello, status, etc.

  • From: Ondřej Kupka <ondra.cap@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sun, 23 Feb 2014 13:28:10 +0100

Didn't know about zenio. I must say that having a native Go implementation
of nanomsg would be pretty useful and perhaps not that hard. Cgo calls are
expensive and it would also make it possible to use Go patterns instead of
fighting the original interface.
Speaking of zenio, not sure we need both zmq and nn. They are basically
doing the same thing, so I would not waste resources doing both at once, at
least at the beginning.
And of course I would love to help. Unfortunately I don't have so much
time. Perhaps I could review some code if it would bring some benefit.

Cheers,
Ondrej Kupka (tchap on GitHub)
On Feb 22, 2014 8:56 PM, "Garrett D'Amore" <garrett.damore@xxxxxxxxx> wrote:

> Hi all,
>
> I have recently started looking at nanomsg as a superior alternative to
> zeromq, and I’m pleased with what I’ve found.  I was able to put together a
> JSON-RPC server of my own device on top of nanomsg really quickly.   I was
> quite pleased with the result.  Admittedly, I’ve not tried building any of
> the other patterns other than REQ/REP yet, but I don’t expect too many
> surprises.
>
> That said, I see that the upstream github repo is rather devoid of
> activity lately.  I’d like to understand whether this is due to lack of
> resource, or a feeling that the project is sufficiently complete to not
> require further investment?
>
> Are folks using this stuff in production yet?  Are there gotchas that I
> should be aware of?  I don’t see anything obvious in the code, but would
> like to know what experiences folks have with it so far.  (Yes, I know its
> officially “alpha”, but reading the code, and understanding the underlying
> design, I feel *far* more inclined to trust this project’s alpha quality
> code than some other projects’ production stuff. :-)
>
> At the same time I’m exploring Go, and would like to bind the two together
> in native Go rather than building against external C.  It seems that Go has
> a concurrency and messaging model that is more naturally suited to nanomsg,
> and based on conversations I’ve had with one of the Go developers (Aram
> Hǎvǎrneanu), I am thinking that linking libnanomsg.a to Go robs the
> application of some of the benefits of Go’s excellent concurrency and
> messaging.
>
> I did find the zenio project here https://github.com/op/zenio and am
> starting to work with it.  I need to extend it to support the ipc:///
> scheme, so that wil be my first area of enhancement.  But it seems like
> this project really could use more investment, and its something I’m keen
> to do.  (Has anyone else here tried using zenio outside of the author?)
>  Admittedly I’m more interested in creating a pure Go implementation of
> just nanomsg than I’m in trying to also support zmq — it seems like that is
> better addressed in a separate project, although having a higher level
> abstraction model (interface) that could support either project doesn’t
> seem like a terrible idea — that should just be a matter of defining the
> proper method signatures.
>
> I’m also concerned about the stability of the wire protocol, as what I’m
> really looking at is investing into enhancing (if based upon zenio) or even
> creating (if starting fresh) a completely independent implementation of the
> protoocols.  (Again, this has *nothing* to do with not being happy with
> libnanomsg in the context of a C application — in fact I really like the
> library both from an interface and from an implementation standpoint.  But
> writing for C is different than writing for another environment, and I
> believe we can make a *superior* implementation *for Go* by doing it in Go
> natively.)  I found the RFC drafts, and they seem to mostly match the code,
> apart from the fact that the current code sends version 0 instead of 1.
>  Are there other differences in the code, or planned that I should know
> about?
>
> I’d also be interested in extending nanomsg to operate over kinds of
> transports.  I’m specifically interested in tunneling it through SSL/TLS
> and HTTPS/websocket.  (This would help allow it to reach across the
> internet without requiring a VPN.)  It seems like this would be a fairly
> straight-forward task to do, just creating additional transports in the
> transport/ directory.   Are there already such efforts underway?  Are there
> strong opinions about such efforts one way or the other?  (Doing this in Go
> would be almost child’s play given a version that works with TCP.  Making
> it work in C means bringing in other libraries like OpenSSL or libcurl,
>  unless one wants to write those protocol implementations from scratch
> which I most assuredly do *not*! :-)
>
> Anyway, sorry for the long rambling message, and thanks for any advice or
> pointers provided!
>
> --
> Garrett D'Amore
> Sent with Airmail
>

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 02-2014