Hi Gonzalo,
Therefore, one must answer: what should be ported to Go? One way to approach this, as it was already pointed out, would be defining the nanomsg protocol and implementing that in Go. Perhaps another approach could be implementing an even more low-level "communications and synchronization engine" in Go that allows you to then implement something like the nanomsg protocol on top of that. This might even make it possible to implement the ZeroMQ protocol on top of that as well (if that makes any sense)... Still, you would have to clearly state what this really low-level engine should be composed from. Perhaps this is exactly what nanomsg has accomplished; I really need to look into the code in more details.
In the C codebase the highest-level architecture looks like this: 1. Core functionality 2. Transports 3. ProtocolsThe core does the job of connecting transports (tcp, ipc, etc.) to protocols (req/rep, pub/sub, etc.) and then to the API.
Transports handle functionality that is specific to a transport, irrespective of the protocol running on the top of it. So, for example, TCP transport implements delimitation of messages within TCP bytestream etc.
Protocols handle the functionality that is specific to the messaging pattern, irrespective of the transport beneath it. So, for example, implementation of subscriptions goes to pub/sub protocol.
When porting nanomsg, I would suggest keeping this clear separation of core/transports/protocols. I haven't done that in ZeroMQ and the consequence is that it's very hard to add new transports and/or protocols.
Just my 2c. Martin
