#56 楼 @tank 暂时没有，以后可能会有。聊天部分是 HipChat (http://hipchat.com).

关闭标签的时候客户端做了啥，服务端做了啥，你自己的代码部分。

#75 楼 @hayeah I hate runit，用起来超级不爽.... 我现在只用 monit

#52 楼 @tank 关闭标签页是指监听 window.onbeforeunload 事件？没法 unsubscribe 消息你查了是什么原因？客户端没发还是发了服务端没处理？

#53 楼 @tank 你是说我做的 live show 吗？不是的，不过我打算跟 @poshboytl 重做时看看能不能搞个系列的，各种技术都尝试一下。

#50 楼 @tank 不是很理解你说的上下线问题跟代码之间的关系。是不是指用户非主动断开比较关掉页面后，仍然显示在线？这个我觉得是有个 timeout 的过程，如果客户端有一段时间没有给你发请求 (心跳) 就认为用户断线。做聊天室的话，我个人会倾向于用 BOSH + ejabberd/openfire，可以看看我的 PPT 里关于 HipChat 这个例子的部分。Faye 没在实际项目中用过，不好乱给意见，不好意思

#45 楼 @bhuztez 为什么？我直接用 ajax 模拟 long-polling (比如 BOSH，Faye 也支持), 或者 jsonp 都可以支持 IE 吧？

#43 楼 @bhuztez htmlfile 已经过时了，有事烧纸

#41 楼 @bhuztez 我没说 htmlfile 需要 flash 啊... 这种基于 http 的跨浏览器本来就是天生的。问题在于 Faye 不支持 htmlfile

#38 楼 @darkbaby123 cool，很好的案例。Faye 对 IM 应该支持的，你去实验一下。htmlfile 不适合你，走 http streaming，还要你自己去开发服务端，已经是很老的东西了。

#51 楼 @fsword 不用 rails s -d 而是直接用 monit / god 这些来管理可能可以绕开这个问题

#32 楼 @darkbaby123 关于网络问题的话，的确国内访问 Pusher 速度并不是非常快，你负载大概在多少，可以尝试下 slanger 这个 gem。Faye 也是有 fallback 机制的，支持 IE，在支持 WebSocket 的情况下也可以直接用 WebSocket 作为 transport。用这些的好处在于服务端的开发量少，基本是内部通讯协议的定义。

#32 楼 @darkbaby123 Pusher 是有 Flash Fallback 的，也就是在有 WebSocket 支持的情况下，用 WebSocket，但是没有的话，就退化成 Flash Socket。你有没有尝试过？文档在这里，http://pusher.com/docs/flash_fallback 在选择实时方案时，从浏览器兼容角度来看，一般都会提供 fallback.

#23 楼 @sanivbyfish 有点奇怪，按理 damonize 后已经跟当前终端进程没关了。cc to @fsword @ruohanc

#13 楼 @sanivbyfish 描述一下你是如何启动这些进程的。你贴的错误是同一个问题还是两个不同的问题。cpanel_app.coffee 的第一行是什么？你是怎么加载这个文件的？

#9 楼 @sanivbyfish 贴点内容，如果那个错误文件

#87 楼 @reducm 外置键盘放笔记本键盘上，trackpad 放你现在鼠标的地方，毫无压力啊。如果只是小巧的话，除了 HHKB，Flico 87 圣手也很小巧的。但是------，大爱我的 HHKB 的说

@sundevilyang 北京的活动多方面发展啊，有意思，加油

#7 楼 @quakewang Mac 下能玩吗？

蜗牛！

@qhwa 非常感谢你的指出，我没有好好去了解 Flash Socket 的具体实现，给大家错误的信息，不好意思。我刚才看了一下，是不是如果走 Ruby Socket Server 这种，就是自定义通讯协议，也可以达到目标？对 Flash 一直比较排斥，很多方面都不了解，你们能有 Web 旺旺这么好的实践平台，多跟大家分享一下这方面的知识，:)。至于 Fallback，比如 Socket.IO 这些库都已经做的很好了，比如可以优先用 WebSocket，如果不支持的话，自动 fallback 到 long polling, flash, etc，都非常的好用。如果考虑低级浏览器或者跨域的话，long polling 也是不错的方式。

#26 楼 @Tony612 Faye 是基于 Bayeux 的 publish-subscribe 消息系统。单独通知的话考虑用 faye, websocket, SSE. 都可以，基本不存在切换的问题。另外，如果不是非 ruby 不可的话，这部分模块其实基于 node 会更方便。

#24 楼 @redvoilin 谢谢关心！

谢谢大家的认可，感动 ing。同时谢谢大家起大早来听我演讲，:)

@ericguo 可惜错过了你的 session，考不考虑做个视频给 @poshboytl, :)

#21 楼 @edokeh 哈。我也又一次拼错了。我觉得 IM 这种就更适合 XMPP 了，所以我觉得... Weibo IM 用 Bayeux 真心无法理解...

#4 楼 @Magic 谢谢关心！

#9 楼 @yzhrain 看你的在线客服要支持到什么程度，:)

#6 楼 @bhuztez 对不住 b 大，配合视频的话有内容点....

#8 楼 @kenshin716 SSE 是使用 http streaming 的，也是不错的选择，单向的服务端推送对很多应用也够了，就像你说的也可以用 SSE + Ajax 来做双向，但是，这样子的话，不如直接上 WebSocket。

#15 楼 同时，我希望未来 WebSocket + XMPP 的组合，有兴趣的可以看看 http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01

#12 楼 @edokeh 看你应用的具体需求。用 BOSH (XMPP) 的好处在于标准化，可扩展性非常高，已经有非常多的扩展可以用了，比如 IM, Chat Room, Pubsub, File Sharing, etc. Google Wave 就是基于 XMPP 做他的实时方案的。他的缺点也是标准化，你需要先了解 XMPP 才能用得好这个东西。可以用 Jabber Client 是一个优点，但不支持也没有任何的关系（你不需要暴露出用户在 XMPP 服务器上的账号信息）。Bayeux 在我看来是一个很小的协议，他把很多事情都留给应用端了，也就是说你需要自己去定义数据格式等，可以做的非常随意，在后期可能会带来维护上的问题。但是，在上手上会比 使用 BOSH 更快。这两个在 Long Polling 的实现技术上没有孰优孰劣，最终还是看你的应用的具体需求。

PS：个人偏好 BOSH。