Well the portability stuff would just be a super thin wrapper around the
internal functions I am already using. And probably exposed via a different
header file with names starting with nng_. I doubt it would make much
difference if you had them in a library and didnt use them.
A CPython port of these would have no reason to expose (and probably no
reason to consume) anything not directly part of the nng messaging API. I
expect that would be true of any of the language bindings except perhaps
C++. (Though in all honesty modern C++ and even C11 would not need these I
think. )
On Sat, Feb 10, 2018 at 4:02 AM Jukka Reitmaa <jukka.reitmaa@xxxxxxxxx>
wrote:
(And when I say 'integrated into' I mean 'integrated with'. Just to avoid
confusion.)
On Feb 10, 2018 09:33, "Jukka Reitmaa" <jukka.reitmaa@xxxxxxxxx> wrote:
I'd be inclined to ensure that any portability layer stuff can
nevertheless be trivially separated from nng proper, so that nng can e.g.
be easily integrated into CPython/libuv/whatnot (although realizing that
these may well be conflicting interests; I'm not that familiar with nng
internals). I'm unsure if I'd have use for another portability layer (which
are also often a somewhat slippery slope in terms of features to be
viable), but I'd certainly have use for a sleek messaging component.
Regards,
Jukka Reitmaa
On Feb 9, 2018 14:38, "Karan, Cem F CIV USARMY RDECOM ARL (US)" <
cem.f.karan.civ@xxxxxxxx> wrote:
I understand. In that case, I think you've already answered your own
question; you need to expose your general portability layer, and deal with
the consequences. Good luck!
Thanks,
Cem Karan
------------------------------
*From:* nanomsg-bounce@xxxxxxxxxxxxx [nanomsg-bounce@xxxxxxxxxxxxx] on
behalf of Garrett D'Amore [garrett@xxxxxxxxxx]
*Sent:* Thursday, February 08, 2018 5:15 PM
*To:* nanomsg@xxxxxxxxxxxxx
*Subject:* [nanomsg] Re: [Non-DoD Source] nng as a portability layer?
All active links contained in this email were disabled. Please verify
the identity of the sender, and confirm the authenticity of all links
contained within the message prior to copying and pasting the address to a
Web browser.
------------------------------
Well I could do that. Or I could just code to POSIX and tell Windows to
go pound sand. The problem is that *I* don’t want to have to mess with APR
or NSS. They are big gnarly beasts, take forever to build, and depending
on them would be an impediment to *me*.
I also would like to have light weight dependencies so that I can
someday at least validate the demos compile (and maybe even test them) as
part of our CI.
- Garrett
On Thu, Feb 8, 2018 at 1:34 PM Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx < Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> >
wrote:
What about just for the demo programs? That way nng isn't making any
promises, but you still have relatively portable demo programs.
Thanks,
Cem Karan
------------------------------
*From:* nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx > [nanomsg-bounce@xxxxxxxxxxxxx
< Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ] on behalf of
Garrett D'Amore [garrett@xxxxxxxxxx < Caution-mailto:garrett@xxxxxxxxxx
> ]
*Sent:* Thursday, February 08, 2018 3:26 PM
*To:* nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
*Subject:* [nanomsg] Re: [Non-DoD Source] nng as a portability layer?
All active links contained in this email were disabled. Please verify
the identity of the sender, and confirm the authenticity of all links
contained within the message prior to copying and pasting the address to a
Web browser.
------------------------------
too big and too much a pain. plus maybe not portable “enough”. (think
embedded. )
On Thu, Feb 8, 2018 at 12:24 PM Karan, Cem F CIV USARMY RDECOM ARL (US)
<cem.f.karan.civ@xxxxxxxx < Caution-mailto:cem.f.karan.civ@xxxxxxxx
> < Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:
cem.f.karan.civ@xxxxxxxx > > > wrote:
Are there any problems with requiring APR or libNSS? Or are they just
too big? That way you wouldn't be reinventing the wheel.
Thanks,
Cem Karan
------------------------------
*From:* nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx > < Caution-Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx > > [nanomsg-bounce@xxxxxxxxxxxxx
< Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx
> < Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx
< Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > ] on behalf of
Garrett D'Amore [garrett@xxxxxxxxxx < Caution-mailto:
garrett@xxxxxxxxxx > < Caution-Caution-mailto:garrett@xxxxxxxxxx
< Caution-mailto:garrett@xxxxxxxxxx ;> > ]
*Sent:* Thursday, February 08, 2018 2:41 PM*To:* nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx
> < Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg@xxxxxxxxxxxxx > >
*Subject:* [Non-DoD Source] [nanomsg] nng as a portability layer?I’m finding, as I write demo programs, that there are a lot of little
things in nng that I’ve used liberally internally, but which I would
really
like to have be more widely available for use in application programs.
I’m somewhat torn about exposing “general” portability layer stuff,
since every exposed API becomes a “promise” and increases the support
surface area. Nonetheless, I think with the AIO framework we have, I am
starting to wonder about adding additional stuff:
* Mutexes and condition variables.
* Trivial linked list management (maybe?? This is easy enough that I
could elide it.)
* Time handling
* Thread creation, and termination?
* General purpose TCP, IPC, and even UDP functionality? (This gets
into a slippery slope I think!)
* General purpose websocket functions?
* General purpose AIO “provider support” (so developers can use AIOs
to handle their own async functionality?)
One can also imagine exposing some stuff I have internally, like
base64 and sha1 (present for websocket), or JSON or TOML parsing (which I
might add later for config file support).
This starts to look increasingly like libuv or somesuch at least in
scope. I hope not to wind up reinventing APR or libNSS.
What opinions do folks have?
- Garrett
