Re: Websockets

Hi Evan,

My 2 cents on XMPP vs HTTP vs WS

>
>    - XMPP comes with a mature underlying model for endpoints (accounts,
>    servers, components) and payloads (messages, ims, presences). That's great
>    if it maps onto what you want to do... otherwise you have to adjust.
>    Websockets is much more like a bi-directional TCP/IP connection. It
>    has practically no model whatsoever.
>
> I don't understand this one. XMPP brings you federation, with a proven
identity and security model, many highly scalable implementations, etc.
You'll have to re-invent all of this in WS world. I'm still convinced that
XMPP would the fastest and most reliable way to bring this federated social
future we dream of.

The only reason to go HTTP (and re-invent things like PubSub, Dialback etc
over HTTP) is developer reach and infrastructure maturity. There are many
more people out there who understand HTTP than XMPP and we've learn for 30
years how to build highly scalable HTTP services.

>
>    - For non-XML payloads, e.g. JSON, you end up doing a lot of
>    XML-wrapping with XMPP. With Websockets, you're free to send just about
>    anything down the pipe.
>
> All depends on how you go about it. You can leave the XML work to the
server and undelying lib and just focus on the payloads. I don't see why
these could not be JSON messages. Replacing salmon by xmpp messages for
cross-domain notifications would be a good start.

>
>
> I think there's room for experimenting with both mechanisms.
>

Of course, keeping an open mind, I like the fact that WS could be used both
at S2S and C2S level. Unfortunately XMPP is missing in the browser and has
to resort to tricks like BOSH. Experimenting is fun and full of learning.
However, in the end, you'll have to reinvent everything XMPP already has
(identity, discovery, authentication, etc etc).

Best,

Laurent