dmcgowan
commented
9 years ago Very understandable confusion at the moment. We hope to be clarifying much of that this week as the new interface from #38 gets merge ready. The motivation behind the new interface is as you said, to implement the PROTOCOL spec. Also as you have noticed the PROTOCOL is still incomplete, we are aware of that and trying to let the needs of the implementation and applications drive the spec. Once the interface is merged we should be able to nail down the spec more so other implementations are not as much of a moving target.
The msgpack extended type definitions are currently missing from the PROTOCOL spec and we will be adding them shortly. I would recommend looking at how they are implemented in the new interface and see if they make sense before we make it official. We are also experiencing a mgspack library situation in go, where the library is limiting what we can do where the msgpack spec does not (hence the fork until it is resolved).
The message 'reply' can be achieved through sending a Sender to the remote side, we should probably add a new example for the interface. Please do comment on any differences you see between the new implementation and the spec so they can be resolved. The goal is to have a spec and reference implementation, so any differences will get resolved.
I will let @shykes respond to your last paragraph.
mcollina
I'm having an hard time to figure out how to implement the libchan over SPDY in nodejs for jschan mainly because there are at least 3 different sources of information: the code, the PROTOCOL file and #38.
What is not clear is exactly how msgpack and the 'libchan-ref' header works. On master there is no msgpack, just urlenconding strings. In the PROTOCOL spec is stated that all messages should be in msgpack format, and #38 implements that.
On master each message gets its own spdy stream, plus a spdy stream for response: master uses the 'parent' relationship of SPDY streams to create all those streams (e.g. the response of a message travels over a SPDY stream that has the current one as parent). This is different to what is specified in PROTOCOL.md, as the 'libchan-ref' header should play some role: however nesting is not documented, and there is no way to 'reply' to a message as in PROTOCOL.md.
In #38, which from what I understand implements PROTOCOL.md, channels are unidirectional but are nestable thanks to an extension of msgpack. In practice, this means that the transport leverage the capabilities in msgpack v5 that allows extension points. This means an extendable msgpack library is needed (which we don't have on node, but that's not the point of the discussion).
Where is the project going? What are the plans? What is the spec of libchan protocol? Will it be all-msgpack for messages (but the README and the purpose of the protocol says otherwise)? As an environment is spawning up around libchan and microservices, I suggest we do drafts like RFC, e.g. we can know library X implements libchan-1, and iterate over that.
Anyway, thanks for all the good work, there is enough stuff here to blow up my head :).
cc @Vertice @peger.