[nanomsg] Re: [Non-DoD Source] nng as a portability layer?

  • From: SGSeven Algebraf <a1rex2003@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sun, 11 Feb 2018 07:52:19 -0500

nng as a portability layer is a fantastic idea!!!  Portability layer can be
viewed as the nng extension. A bonus really! A cherry on the cake!

Why any one, sane enough, would want to invent its own time handling, general
purpose TCP, IPC and so on if all of these are for grab inside nng?


nng has many layers of gold. Those layers are hidden at this moment. Let
them shine through!


I am really exciting about nng and about those extra functionalities which
could be reused in so many projects dealing with network connectivity or
even just generic programming!


Thank you and kind regards,
- Samuel


On Sun, Feb 11, 2018 at 2:21 AM, Jukka Reitmaa <jukka.reitmaa@xxxxxxxxx>
wrote:

Ok, thanks for elaborating. Sounds quite reasonable.

On Sat, Feb 10, 2018 at 4:56 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
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@
freelists.org
 < 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


Other related posts:

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