> Last, about Soap over TCP, well, that is probably not something we in
> Apps
> Area like. Beep solves an important problem we have, which is
> abstraction
> of the transport layer, so things end up being "nicer" to TCP.
> Remember all
> discussions a year or two ago about a generic application layer
> protocol?
Frankly, I don't see what the "abstraction of the transport layer" provides you. If
you are saying that we should allow reuse of the TCP connection for multiple SOAP
messages, that is fine. But BEEP is hardly the only way to achieve that.
> It's certainly better (from an architectural standpoint) than HTTP
> regarding "generic protocol for transport of application layer
> messages".
> HTTP is today extremely complicated, and just that should scare people
> away
> which doesn't work with traditional "web related things".
Well, HTTP has at least the benefit of being widely implemented and widely used. That
is not the case for BEEP. I personally find BEEP quite atrocious. It introduces a
"channel" artifact that is gratuitous complexity; it breaks at least one fundamental
rule of networking, by allowing for multiplexing on top of TCP.
The designers of BEEP probably had some applications in mind; this is a free world,
and they are welcome to try. But presenting BEEP as the favored solution to most
application is very premature.
-- Christian Huitema
