I think Gotalk and Kite have a lot of common (for example we have also kite.js, to talk with browsers). The mission of the Kite library is the same as with Gotalk, mainly to communicate two pieces of software in an easy way. However in order to achieve this Kite also has an inbuilt service discovery mechanism. I think this is really important because with time you are app number will increase and service discovery is a must have. There are many differences too, for example protocol (we use JSON).
Congrats on shipping this, I'm really looking forward to see how it evolves and how you solve upcoming problems (such as poor network conditions where Websocket badly fails).
Hello Farslan, I'm the author of Gotalk and just read your article on Kite — very interesting!
In the scenario of composing distributing systems where you'd e.g. want to "map-reduce this data on some number of cores" service discovery is important. However I wrote Gotalk to be as small as possible, meaning I hope it can become one of those small packages I feel comfortable using in any of my projects. The "small" part here is key: that it feels small.
Perhaps there's an approach where a completely decoupled service-discovery package exists which can be combined with Kite or Gotalk to form auto-discovering clusters of programs.
Wouldn't it be more fair to compare Gotalk to Kite's underlying dnode-protocol[1] ?
Personally Gotalk's protocol seems much better thought out; size-prefixed messaging, rpc & streaming support, multiplexing (especially important with WebSocket).
The only missing bit would be some form of heart-beating.
With Gotalk, you can use the byte-buffer request and response functionality (instead of the JSON-encoding versions) and e.g. dec.XORKeyStream(inbuf, payload) in your handler when receiving a payload followed by enc.XORKeyStream(payload, outbuf) when responding.
You could add symmetric encryption before and after putting anything on the network, and let users turn it on with a simple setting. Here's the fun part: you could use go generators to create a local key when the package is compiled. Then you wouldn't need to embed a key, or ask the user to generate and pass in a key.
This looks a lot like Open RPC, formerly Sun RPC (https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_...) It's a binary-format remote procedure call. Why not just implement that for Go? Then you can interoperate with existing implementations for other languages. There are lots of standards for this sort of thing, from SOAP to Google Protocol Buffers.
Opening this up for connection to potentially hostile nodes requires more design. What about denial of service problems? Can someone open a connection and tie up resources?
Awesome work, congrats! IMO it would be great if the serialisation/pipelining protocol was decoupled from this library so that you could easily create compatible clients and servers in a language other than Go.
If you have a look at protocol.go as well as the "Wire format" section of README.md, you'll find that the Gotalk protocol is decoupled from the Sock type, handlers and other parts of the Go package. The JavaScript implementation similarly provides protocol functions in js/gotalk/protocol.js — I hope I didn't misunderstand your question :)
I worked on a project using Akka (Scala), and this seems to have the same core aspects as that (well, it's just message passing but easy to set up and thel like). Hope this catches on, seems like a very promising library
Akka makes some impressive claims, like 400 bytes of memory usage for an entire actor "coroutine." I'm not well-versed in Scala, but it looks like a pretty novel API (i.e. the GreetingActor example et al.)
Nice project! The callbacks on event listeners reminds me a lot of javascript and can get messy. Go handles this with channels. Why did you decide not to use channels to emit events?
I think Gotalk and Kite have a lot of common (for example we have also kite.js, to talk with browsers). The mission of the Kite library is the same as with Gotalk, mainly to communicate two pieces of software in an easy way. However in order to achieve this Kite also has an inbuilt service discovery mechanism. I think this is really important because with time you are app number will increase and service discovery is a must have. There are many differences too, for example protocol (we use JSON).
Congrats on shipping this, I'm really looking forward to see how it evolves and how you solve upcoming problems (such as poor network conditions where Websocket badly fails).