Suggested order of implementation for the libchan protocol

[AdrianRossouw]

I'm in the process of researching and designing a node.js/javascript implementation of libchan (i'm calling it Graft).

I'm planning to use node streams as the base of the abstraction, and i'm aiming for a api similar in usage to gulp.

What I'm wondering is, what you would consider the simplest proof of concept to bootstrap this implementation, so that I can iterate on the various components from there.

So I guess, what does 'hello world' look like for libchan?

[jbenet]

A set of examples of common patterns would be nice.

[AdrianRossouw]

We've started building out jschan. We have taken the java implementation's lead and started by porting the tests.

next we are going to be picking a SPDY implementation to evaluate, and see if we can get enough of the channel semantics going to get something running.

I was thinking an interesting example project (think xgears) could be a server and a client sending bytestreams between each other that they need to be working properly to calculate (like maybe hashing the body against a streaming checksum of the data transferred over the spdy pipe?)

[AdrianRossouw]

was speaking to @shykes in irc, and mentioned we want to do the unix implementation next since it looked like an easy port.

He told us :

shykes: watch out, the current unix implementation is behind the spec
shykes: we want to unify it with the tcp one
shykes: right now unix/ has its own custom framing, we want to get rid of that in favor of spdy
shykes: we just need to figure out a clean way to inject FD passing in the underlying unix transport, while keeping the spdy transport
shykes: (so that bytestreams can be passed as raw FDs)
shykes: gotta run for now, will catch up later today

[AdrianRossouw]

These are the next tasks for the js implementation ( from the graftjs meeting minutes )

ping @ndeloof , you have any other ideas for what next?

[ndeloof]

@Vertice I guess a major part of this will be to test cross implementations compatibility. On jchan my plan for next cycle is to look into a tcp implementation, then spdy (need to find a reasonable java impl for it)

[AdrianRossouw]

@ndeloof yeah, which is why i suggested the ping-like example app.

we could write that in every language, and use that to bootstrap the implementations. Something like it could even be used on a per-transport level.

[pnasrat]

Typical network apps are echo server, discard, daytime, time, chargen. I think those as hello world for libchan is reasonable (send/valid respond, send only, send/dynamic responses, infinite stream)

[AdrianRossouw]

We managed to get compatibility with the go version over SPDY and tcp. To to close this issue we should do a bit of a writeup about the process we followed. @mcollina, correct me on this if i'm wrong.

1. figure out basic language primitives (streams for us)
2. port in-memory tests to chosen language.
3. first stab at an api.
4. build in-memory transport.
5. example app ( in memory app)
6. find msg pack implementation. (we wrote our own)
7. find spdy implementation. (we used node-spdy)
8. port tcp tests to your language
9. build tcp/ip implementation transport.
10. port rexec example application.
11. ???
12. profit

it is still a bit of an open question as to which version of libchan we support, and how to detect when that changes.

Considering how much SPDY and MSGPACK5 implementations vary between languages, I think the picture here is also more of a support matrix than a simple list.

Tests should be fairly automate-able once built though, but that still requires there to be an official 'version' of the protocol to support.