[nanomsg] Re: hello, status, etc.

  • From: Aurélien Vallée <vallee.aurelien@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sat, 22 Feb 2014 12:00:06 -0800

I would also like to have some status on the development. It has been 5
month since the mast commit on github. I was considering adding nanomsg to
debian repositories, but that may be too early? is nanomsg still under
development?


On Sat, Feb 22, 2014 at 9:39 AM, 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
>



-- 
Aurélien Vallée
Phone +33 9 77 19 85 61

Other related posts:

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