TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Gotalk

132 点作者 tbassetto超过 10 年前

12 条评论

farslan超过 10 年前
I&#x27;m one of the Core authors of the Kite library (library for writing micro services). I wrote an extensive introduction here on GopherAcademy: <a href="http://blog.gopheracademy.com/birthday-bash-2014/kite-microservice-library/" rel="nofollow">http:&#x2F;&#x2F;blog.gopheracademy.com&#x2F;birthday-bash-2014&#x2F;kite-micros...</a><p>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).<p>Congrats on shipping this, I&#x27;m really looking forward to see how it evolves and how you solve upcoming problems (such as poor network conditions where Websocket badly fails).
评论 #8932922 未加载
评论 #8932055 未加载
Animats超过 10 年前
This looks a lot like Open RPC, formerly Sun RPC (<a href="https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Open_Network_Computing_Remote_...</a>) It&#x27;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.<p>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?
评论 #8933633 未加载
mjs超过 10 年前
The author was Spotify&#x27;s original designer:<p><a href="http://rsms.me/about/spotify/" rel="nofollow">http:&#x2F;&#x2F;rsms.me&#x2F;about&#x2F;spotify&#x2F;</a>
gtaylor超过 10 年前
If anyone is interested, I&#x27;ve started playing around with a Python implementation here: <a href="https://github.com/gtaylor/python-gotalk" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gtaylor&#x2F;python-gotalk</a><p>I&#x27;m mostly focused on the marshalling&#x2F;unmarshalling of the various message types right now.
fishnchips超过 10 年前
Awesome work, congrats! IMO it would be great if the serialisation&#x2F;pipelining protocol was decoupled from this library so that you could easily create compatible clients and servers in a language other than Go.
评论 #8933211 未加载
tobz超过 10 年前
What&#x27;s the major difference between Gotalk and Socket.IO?
评论 #8932067 未加载
rtpg超过 10 年前
I worked on a project using Akka (Scala), and this seems to have the same core aspects as that (well, it&#x27;s just message passing but easy to set up and thel like). Hope this catches on, seems like a very promising library
评论 #8933763 未加载
thebyrd超过 10 年前
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?
kbd超过 10 年前
Does this improve at all upon Cap&#x27;n Proto RPC?<p><a href="https://capnproto.org/rpc.html" rel="nofollow">https:&#x2F;&#x2F;capnproto.org&#x2F;rpc.html</a><p>Why not use that?
toxik超过 10 年前
Nice thingy, I always loved the writing style of Rasmus. Good work, and stellar exposition.
评论 #8933216 未加载
xcombelle超过 10 年前
Only 3 bytes for requestid ? is not too few ?
sneak超过 10 年前
What&#x27;s wrong with json-rpc?