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