Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make protocols "pluggable", or at least optional #38

Closed
gdamore opened this issue Aug 8, 2017 · 0 comments · Fixed by #51
Closed

Make protocols "pluggable", or at least optional #38

gdamore opened this issue Aug 8, 2017 · 0 comments · Fixed by #51
Labels
enhancement

Comments

@gdamore
Copy link
Contributor

gdamore commented Aug 8, 2017

We should contemplate ways to remove the hardwired list of protocols. Probably some of these need to be compile time builtin by default, but arguably even then it can be controlled via conditional compilation.

It would also be nice to make it possible for 3rd parties to extend the protocols by giving them a wa to register new protocols with the framework. Probably the API needs to be versioned, because the internal guts of the communication between the core and the protocols is not very "clean", and it might be hard to separate them fully. (That said, some of the work there is already done.)
@gdamore gdamore mentioned this issue Aug 9, 2017
Closed
gdamore added a commit that referenced this issue Aug 9, 2017
@gdamore
fixes #44 open protocol by "name" (symbol) instead number
b5eeef8 
fixes #38 Make protocols "pluggable", or at least optional

This is not a full fix, but a good start.  The bus protocol has
a new constructor for opening sockets, and the version number of
the protocol is explicit as part of the open() operation.  (TBD:
should we add an implicit one as well?)

Additionally, there is a nice way for protocols to plug in via
an nni_proto_open(), where they can use a generic constructor
that they use to build a protocol specific constructor (passing
their ops vector in.)

The pluggable protocols are not yet #ifdef'able, and the compat
core will need to know the constructors, but the rest of the
framework need not.  Eventually we should be able to kill off
the nng_open() altogether, meaning that the core can lose all
knowledge it has of the individual protocols.  (Again, this won't
be possible for compat mode, unfortunately.)
gdamore added a commit that referenced this issue Aug 9, 2017
@gdamore
fixes #44 open protocol by "name" (symbol) instead number
3be7663 
fixes #38 Make protocols "pluggable", or at least optional

This is a breaking change, as we've done away with the central
registered list of protocols, and instead demand the user call
nng_xxx_open() where xxx is a protocol name.  (We did keep a
table around in the compat framework though.)

There is a nice way for protocols to plug in via
an nni_proto_open(), where they can use a generic constructor
that they use to build a protocol specific constructor (passing
their ops vector in.)
@gdamore gdamore mentioned this issue Aug 9, 2017
Merged
gdamore added a commit that referenced this issue Aug 9, 2017
@gdamore
fixes #44 open protocol by "name" (symbol) instead number
d64f125 
fixes #38 Make protocols "pluggable", or at least optional

This is a breaking change, as we've done away with the central
registered list of protocols, and instead demand the user call
nng_xxx_open() where xxx is a protocol name.  (We did keep a
table around in the compat framework though.)

There is a nice way for protocols to plug in via
an nni_proto_open(), where they can use a generic constructor
that they use to build a protocol specific constructor (passing
their ops vector in.)
@gdamore gdamore mentioned this issue Sep 6, 2021
Closed
muryliang pushed a commit to muryliang/nng that referenced this issue Mar 30, 2023
@gdamore
fixes nanomsg#38 Applications should not have to call socket.AddTrans…
edd3a10 
…port()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fixes #44 open protocol by "name" (symbol) instead number nanomsg/nng
1 participant
@gdamore