Lists Home |
Date Index |
Paul Prescod wrote:
> I see nothing in BEEP that indicates that has built upon those years of
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." 
> 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
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.
 <URL: http://beepcore.org/beepcore/about_qanda.jsp>