The other night I was introduced to something called Bayeux by a fellow at a local meet up. It seems like an ideal way to fight the known limitation on scalability that Soashable (and XEP-0124 in general) will inevitably suffer from when the service goes live.

At first glance it appeared that Bayeux didn't quite fit the bill for this type of one-on-one client<->server session, due to its channel subscription and indiscriminate repeating behavior. But alas, it is indeed possible without hackery because of the reserved /service/* channel name space that is specifies.

The problem with the XEP solution is that it specifies a client must use an XmlHttpRequest (or equivalent) connection in such a way that limits it by the beloved same origin policy. As a result, in order to be functional (with a non Java web server), a proxy must sit in front of the main web site and funnel jabber http binding requests to the binding server. This could be hardware, software or Apache/lighty mod_proxy. For example: soashable.com is running Apache on port 80, serving up content and Javascript; and the HTTP binding servlet (for XEP-0124) through Jetty on port, say, 9999. Because of the same origin policy, XmlHttpRequests can only talk to soashable.com on port 80. In order to bridge the gap, one needs to use the proxy on port 80 and pipe certain requests to Jetty on port 9999 (two servers can't occupy the same port). In this case we could reduce overhead by using mod_jk, but we are ultimately still tied to having a heavy-weight process for each and every COMET connection, and that will not scale well.

In addition to the limited scalability of the XEP, I can't begin to count the hours I've spent tweaking xmpp4js's polling code due to policy-violation disconnects. The XEP basically defines its own version of what Bayeux specifies, and each client implementation must reinvent the magic. In fact, section 1.4.5 i of the Bayeux 1.0 draft spec is functionally identical to the protocol that the XEP lays out. This means that 1) replacing the polling code with a Bayeux polling client is trivial, and 2) it doesn't make sense to not use a spec and libraries that made for the specific task of polling; they can do one thing and do it well, while the Jabber programmer can worry about their Jabber. Bayeux can be thought of as a socket implementation for Javascript.

I've spent a few hours over the past couple days messing with the clients and servers of Bayeux and it is all very immature. But there is a very active community of people pushing it forward. I'm extremely excited to push forward with it when it stabilizes a bit, and possibly even put forth a new XEP to supersede XEP-0124 if nobody else does it first.