Garrett, we're all aware that the API is still unstable, and I for one would
prefer a GOOD API over one that is stuck (and not as good as it could be)
before it reaches 1.0. So my vote is that you go ahead and make the change if
you think it will make things better.
Thanks,
Cem Karan
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Monday, March 26, 2018 3:59 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] NNG Raw mode sockets
All,
I’m seriously considering to change the API for raw mode sockets slightly, for
the NNG API.
Right now, I permit a socket mode to be “changed” to RAW, or from RAW to COOKED
using a socket option. I did this to match the design I made in mangos, even
though legacy nanomsg doesn’t permit this (the cooked vs. raw mode is ‘fixed’
at socket creation time.)
It turns out that permitting the mode to be changed leads to some sticky corner
cases, especially in the new context stuff I’m working on. I’m actually
finding it really constraining to support changing the socket mode
(particularly, in this case, if one permits changing the socket mode *after*
obtaining any notification file descriptors.)
I’d like to change the raw mode to use an explicit constructor. So we’d have
like:
nng_req0_open_raw(). the existing API nng_req0_open() would only be able to
create cooked mode sockets.
I’d still have the NNG_OPT_RAW option, but it would be come a readonly socket
option.
I don’t think there are many of you out there writing raw mode sockets using
the new style API. Any opinions? Will this be simply too disruptive?
(Technically the API is still marked unstable, but as I’ve been asking more
people to start testing, I’m cognizant of the impact of changing key APIs like
this as close as we are to the 1.0 release.)
- Garrett
I������j� �&���ڞ�����zX���+�f��)��+-N�jz&�h��Z���� 'jz&�
+�:.�˛���m��z�^����}� j�0���zX���+
