Wire-format specification

[M1cha]

According to the old website, nanomsg is a library and not a protocol. The question is: Do we want to change that?
Now that there are two C-implementations(nanomsg and nng) which claim to be wire-compatible and e.g. the go implementation is written in pure-go I think it'd make sense to change that.

I think it's very preferable for compiled languages like go and rust to not just wrap a C library and instead have their own implementation for a multitude of reasons like safety or code-size-reduction(by using existing libraries for e.g. cryptography).

That would be easier to do if there was a specification which can be followed by these implementations instead of just looking at what nng does. Ideally, nng would fully adhere to that spec as well meaning the spec would be changed before nng so it would never become out of date.

Another advantage of this is that the specification could serve as the wire-format documentation which - I'm sorry to say - is really bad right now with old rfcs like sp-publish-subscribe-01.txt containing Blah-blah all over the place just being the highlight.

So the question is: Would you be interested in shifting the scope of nanomsg from a library to a specification like that?

[gdamore]

You've certainly found at least some of the specifications, although there are some newer ones that I started. So I'm largely in agreement with this. But as with all things, it takes time to do this.

Note that I'm planning to make some wire-protocol level improvements which I will certainly document.

Have you discovered https://github.com/nanomsg/rfcs yet?

[gdamore]

By the way, the library form of libnanomsg would ideally be referred to as just that, not nanomsg.

[M1cha]

I saw the RFC repo while writing this issue but didn't read it because the latest commit is from 2018.

[M1cha]

Ok there seems to be some useful info in that repo. Is that in the RFC repo because they're not done?
Where would they end up after finalization?

EDIT: nvm, apparently my understanding of what an RFC is was wrong. I now understand that the rfc repository is supposed to hold all specifications.

[gdamore]

Correct -- the intention is that this would be a common repo for the specifications, separate from source code for any specific implementation.

[gdamore]

(There are no changes to the wire protocols that have been made since 2018 btw.)

[endeavour]

Is there any documentation on the wire format for the push/pull protocol? I would like to write a wireshark dissector to help with debugging application issues.

[gdamore]

Not other than the most basic stuff... basically it doesn't have any extra framing, so its just the negotiation phase and framing that is specific to each transport, and not specific to PUSH/PULL.