Re: [hybi] WebSockets feedback (Was: Bayeux / Jetty perspective.)

[Paul Prescod <[e-mail]>]

As I said, Jabber is probably a better fit. But if it were to use HTTP I
would not suggest to use the "surface syntax". If it were to use HTTP then
it would just add the minimum required to reverse the communications
direction:
 * http://www.ietf.org/internet-drafts/draft-lentczner-rhttp-00.txt

Then you would use one socket for initiator to listener communications and
another for the reverse. Any HTTP client library that is smart about
persistent connections could be quickly adapted to send "server->client"
messages.

But in any case, given that the dominant use case is web chat and Jabber is
the ascendent web chat protocol, I do think that Jabber is a better choice.

On Fri, Apr 3, 2009 at 9:36 AM, Maciej Stachowiak <[e-mail]> wrote:

>
> On Apr 3, 2009, at 9:21 AM, Paul Prescod wrote:
>
>  In general, the benefit of using an existing protocol is that you take
>> advantage of a lot of infrastructure and in particular of protocols built ON
>> TOP of that protocol. Maybe that doesn't matter for train control, but it
>> matters a lot for webchat, which as far as I'm concerned is the single
>> biggest application of a "server->client" protocol. To me, this strongly
>> suggests Jabber, but I'll make the case for HTTP because I'm more familiar
>> with it:
>>
>
> I think basing this protocol on the surface syntax of HTTP is a bad idea.
> HTTP is a request/response protocol, but the new protocol is simply two-way
> messaging. Messages are not (at least so far as the protocol knows)
> requests, nor are they responses to other messages. HTTP has the baked-in
> idea that messages are either requests or responses, that every request gets
> a response, and that every interaction is initiated by the client side.
> Using a similar framing syntax with totally different semantics is unlikely
> to make it easy to adapt existing tools.
>
> Regards,
> Maciej
>
>