[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod wrote:
> I see nothing in BEEP that indicates that has built upon those years of
> work.
Well, it was designed by Marshall Rose based on his (considerable!)
experience with existing protocols as "kind of a 'best hits' album
of the tricks used by experienced application protocol designers
since the early 80's." [1]
> 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.
> You'd have to start from scratch on top of it.
> As far as I can see, BEEP is a connection oriented protocol which means
> the first thing you'll have to do is figure out a connection-less
> profile and reinvent connection-less session state. AFAICS BEEP has no
> notion of resources or representations of them. It consciously and
> explicitly leaves out URIs, which are the core of the REST model. etc.
> etc. BEEP looks like an interesting bit of engineering but it would be a
> MAJOR effort to rebuild a REST-oriented application protocol on top of
> it.
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. For applications that fit
naturally into the REST architecture (web-page fetching, print
spoolers, online purchasing, etc.,) HTTP would be a better choice.
IOW: HTTP is good when a typical session consists of a single
POST or GET; BEEP is good when sessions get more complicated.
[1] <URL: http://beepcore.org/beepcore/about_qanda.jsp>
--Joe English
jenglish@flightlab.com
|
