Re: [hybi] Random Responses

[Jamie Lokier <[e-mail]>]

Mridul Muralidharan wrote:
> Yes, BEEP does fit the requirements discussed so far ...

BEEP doesn't meet the requirement for simple implementation because it
requires every implementation to parse XML.  HTTP does not.

Also BEEP's per-channel setup latency is rather large: one redundant
round trip.  Using BEEP for a simple HTTP request would take noticably
longer than HTTP itself on high latency networks.

> (not to mention support for flow control which becomes immediately
> necessary in bi-directional streams).

BEEP's flow control is sensible, but that's not the reason for it.

For bi-directional streams, TCP/IP's built in flow control is enough.

If you imagine a bi-directional HTTP (easy because requests and
responses are easily distinguished), it does not need any BEEP-style
flow control.  (I have implemented this).

BEEP-style per channel flow control is needed because of its ability
to multiplex multiple channels in the _same_ direction on a single
TCP/IP stream.  Without per-channel flow control you get deadlocks or
infinite buffering needed in some practical uses.

Unfortunately BEEPs per channel flow control is sensible, but it's per
channel setup is expensive both in needing XML and in network round
trip time.  It would be good to keep the flow control but use smarter
channel setup.

> Flip side would be, I am not sure if it is upgradable from HTTP with
> current infrastructure - other than through CONNECT that is.

It's not, but all protocols discussed can be overlaid onto the current
infrastructure using the HTTP hacks we use today (long GET etc.),
while giving new proxies the chance to recognise the overlaid protocol
and participate in it properly (dropping the hacks, proxying better).

Imho it would be good to discuss how we can overlay any new protocol
that we're talking about compatibly onto the existing HTTP infrastructure.

-- Jamie