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> 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 [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
