If you wanted to put together a trial branch so we can see what it would
look like, I’d be happy to have a look. If its not invasive, I don’t see
any reason we couldn’t enable this —perhaps as a conditional output from
CMake.
On Fri, Sep 15, 2017 at 11:35 AM Michael Powell <mwpowellhtx@xxxxxxxxx>
wrote:
On Fri, Sep 15, 2017 at 1:46 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
I don’t have experience with SWIG, since I work primarily in C or Go.The
one drawback I can see is that SWIG appears to be GPLv3, which is a moreapply
restrictive license than nng or nanomsg. It looks like that does not
to it’s output, so maybe this is a non-issue.
Don't know about the licensing, per se; but supposing it is like you
say, sounds like the output would be fine.
Another thing that occurs to me is that SWIG seems to just take the C APIthe
and expose it to other runtimes. This may be the simplest way to expose
API to other languages, but I think it may miss the opportunity to buildcan
APIs that are more idiomatic for those languages. (That said, maybe you
use SWIG to create a “bottom” layer, and then build an idiomatic API ontop
of the SWIG output?)
Yes, exactly. When I think about "bindings", and at the risk of
oversimplifying, that's basically what we're talking about, anyway,
correct? Notwithstanding language or runtime nuances. In other words,
exposing the API into target languages and runtimes.
I do a similar thing, using Google OR-tools as a model, as a basis for
doing C# / .NET idiosyncratic things. So, yes, for python-isms or
java-isms, a similar thing could be done along those lines.
Still and all, I’m happy to see folks explore and experiment with this
stuff, to find out what works best for them!
Well, I'll just put this on the table then, otherwise we're talking
about nothing. I'd propose to introduce SWIG to the base repository,
as contrasted with, say, a fork, or a sub-module. The closer SWIG is
to the source of the dependency pipeline the better it works IMO.
I'd be interested to start simple and fold in new bindings
incrementally. It can be easily supported with Make; and I assume
CMake as well.
- Garrett
Cheers,
Michael
On Fri, Sep 15, 2017 at 6:47 AM Michael <mwpowellhtx@xxxxxxxxx> wrote:like
I may be interested in applying swig to nng. No sense working harder on
something if swig can generate it for you. Possibly even to embedded
systems, i.e. with nominal cross compilation. I'm thinking of things
garrett@xxxxxxxxxx>arch-linux, for example. Anyway, let me know what you think.
On September 15, 2017 2:08:34 AM EDT, Garrett D'Amore <
indeedwrote:
Hi all,
Just a quick note to catch folks up. Nanomsg is still alive, and
throughI’m working on the next generation (libnng). This library has gone
timea lot of evolution lately, and while it isn’t quite ready for prime
notice.yet, it probably is ready for folks to begin testing it out.
I can’t promise I won’t break the API in the future (I probably will
actually), but unless you’re using the event API you probably won’t
startThe nanomsg compatible legacy API will *not* be affected, so you could
thatwith that.
Also, I’ve been working on a new transport, ZeroTier, which allows a L2
style transport using nanomsg over a “global Ethernet”. This is pretty
cool, and you should check out ZeroTier for more on it. (The work on
though!)transport is a sponsored effort, btw.)
The ZeroTier nng transport is still in development (nearly done
port itand so I can’t recommend it for use yet. but that will change soon.
At this point, I’m ready to start engaging with other folks who want to
help in the nng effort. The tasks that remain to be done for nng (with
which I can use help) are:
a) Coding. Several transports (TLS, and websocket, possibly others).
Statistics support, more options. Also, I’m interested in working with
folks who want to make nng more performant on various platforms, or
remainsto new platforms (embedded systems!)
b) Example programs and documentation. (Especially documentation!)
c) Test coverage. I’ve written a number of test cases, but there
foropportunity to create a lot more test cases to improve the coverage.
d) New patterns. I think there are some interesting ideas to explore
list.developing new patterns, some of which have been discussed here on the
your
I’m happy to work with folks 1:1 who want to help out; if you’ve been
thinking of contributing effort into an open source project, here’s
opportunity! Just drop me an email!
Thanks!
- Garrett
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
