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 [nanomsg-bounce@xxxxxxxxxxxxx] on behalf of
Garrett D'Amore [garrett@xxxxxxxxxx]
Sent: Thursday, February 08, 2018 3:26 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.
________________________________
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 ;> > 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 ;> [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 2:41 PM
To: 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
