3 ms·
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 commu
by 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 agoSure, 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 agoI 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.