|
It's funny to hear BEEP promoted over HTTP, for several reasons.
First, is because they're different types of protocols; BEEP is a presentation layer protocol, where HTTP is application layer. So any comparison (almost, see below 8-) is apples-to-oranges.
Second, both attempt to solve a similar problem; how can we build commonality between the multitude of application protocols out there, and those yet to come? BEEP's answer is to build a common lower layer on which application protocols can be built, while HTTP's answer is to be an application protocol whose semantics are so general as to be able to engulf many other protocols (as FTP and Gopher have been engulfed). The advantage of BEEP's approach is that a large number of application protocols can be built this way, say 90%. And while HTTP is perhaps only suitable for, say, 70% of them, it's principle (huge!) advantage is that it defines interoperability *between* applications. For example, Yahoo can link to both stock quotes and sports scores, while a BEEP based "stock quote" application has no meaningful way to interoperate with a BEEP based "sport scores" app. This means that there are minimal, if any, network effects generated by BEEP's common layer, whereas HTTP's general application semantics induces huge effects. That's why I don't think BEEP will see much success, and why HTTP will continue to grow in use, even beyond browsers and humans.
|