[
Lists Home |
Date Index |
Thread Index
]
Joe English wrote:
>
>...
>
> > It doesn't even claim to be a protocol at the same level of the
> > protocol stack as HTTP.
>
> If you see HTTP as an application-layer protocol for displaying
> Web pages, then no; if you see it as a session/presentation-layer
> protocol for building Web services -- which AIUI is part of the REST
> philosophy -- then it is.
No, it isn't part of a session/presentation-layer. It is an application
protocol where the application is the Web, where the Web is defined to
be: "the universe of network-accessible information, the embodiment of
human knowledge." -- which of course includes purchase orders and
widgets-for-sale.
Enough hand waving. What does this mean concretely? The Web has an
addressing model and a way of giving state addresses. I think this is
what makes it an application protocol. BEEP explicitly chooses not to
have an addressing model which makes it a point-to-point session layer,
and cannot be used as a coordination language. Personally, I think that
in this day and age there is an obvious choice for an addressing model
but...
>...
> Agreed. BEEP is better for applications that require a more tightly
> coupled ongoing dialogue between endpoints than what REST/HTTP
> provides. For instance BEEP would be a better foundation for an
> instant messaging system than HTTP.
I've seen some pretty good instant messaging systems built on HTTP but
you need to tunnel it over an existing connection layer to avoid TCP
setup costs. BEEP would be a good session protocol if firewall admins
allow it.
>...
> IOW: HTTP is good when a typical session consists of a single
> POST or GET; BEEP is good when sessions get more complicated.
The word session is somewhat ambiguous. BEEP is good when a typical *TCP
session* consists of more than a single GET or POST. If you wanted to
scale BEEP up to a transaction that lasted several days over network
outages then I think you'd run into big problems. Without a standard
addressing model there is nowhere to "put" data that needs to survive
longer than the session. You'd need to add that sort of feature at the
application layer, I think. With HTTP you would typically store a
session ID in the URI and it survives until one side or the other
deletes it, no matter what happens on the network.
Paul Prescod
|
