5 ms·

The back end is golang. The client server messaging protocol is BrowserChannel/WebChannel. https://code.google.com/p/libevent-browserchannel-server/wiki/Browse

The back end is golang. The client server messaging protocol is BrowserChannel/WebChannel. https://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol https://code.google.com/p/libevent-browserchannel-server/wik... We open sourced the BrowserChannel library here: https://github.com/samegoal/wc https://github.com/samegoal/wc And have a chat room demo app here: https://github.com/samegoal/wcchat https://github.com/samegoal/wcchat The code we used for this particular site isn't Open Source yet. We are still trying to figure out what we want to do with it before we make that decision.

scrollaway 12y ago
Good luck with it. I hope you open source it. Would you be able to give a rationale on why you chose against xmpp?
- ahochhaus 12y ago
  Hi scrollaway. Thanks for the support. XMPP seems really great in a context of needing to inter-operate with other servers. However, for our use-case all communication was in a silo of a single site so this was not a major benefit to Drop-In Chat. Our team wants broad broad browser support (for legacy corporate deployments) and a well-tested client side module. BrowserChannel, which is used for gmail chat, is very widely deployed and well tested. Maybe I'm missing something, but even if we went with XMPP, wouldn't Drop-In Chat still need a way to stream messages from the server to the client? If so, we would still need to rely on a transport mechanism like websockets/XHR streaming/forever iframes for the in-browser real time message delivery. BrowserChannel/WebChannel bundles up this abstraction nicely and hides all the ugliness of dealing with browser quirks for streaming message delivery.
  - scrollaway 12y ago
    Sure, but BrowserChannel is only relevant on the client. What about the server? Using XMPP would allow for external clients to connect for example.
    - ahochhaus 12y ago
      I agree. If at some point dropinchat.com allowed for messaging between networks XMPP support would be great to add. At this point we only allowing for messaging other drop in chat users so no such protocol is needed. My only point was that we didn't "reinvent the wheel" by not using XMPP. Instead we just don't allow cross network messaging yet.

scrollaway 12y ago

Good luck with it. I hope you open source it. Would you be able to give a rationale on why you chose against xmpp?

ahochhaus 12y ago
Hi scrollaway. Thanks for the support. XMPP seems really great in a context of needing to inter-operate with other servers. However, for our use-case all communication was in a silo of a single site so this was not a major benefit to Drop-In Chat. Our team wants broad broad browser support (for legacy corporate deployments) and a well-tested client side module. BrowserChannel, which is used for gmail chat, is very widely deployed and well tested. Maybe I'm missing something, but even if we went with XMPP, wouldn't Drop-In Chat still need a way to stream messages from the server to the client? If so, we would still need to rely on a transport mechanism like websockets/XHR streaming/forever iframes for the in-browser real time message delivery. BrowserChannel/WebChannel bundles up this abstraction nicely and hides all the ugliness of dealing with browser quirks for streaming message delivery.
- scrollaway 12y ago
  Sure, but BrowserChannel is only relevant on the client. What about the server? Using XMPP would allow for external clients to connect for example.
  - ahochhaus 12y ago
    I agree. If at some point dropinchat.com allowed for messaging between networks XMPP support would be great to add. At this point we only allowing for messaging other drop in chat users so no such protocol is needed. My only point was that we didn't "reinvent the wheel" by not using XMPP. Instead we just don't allow cross network messaging yet.