I hadn't thought of adding SASL to SPDY. I haven't dived into the community, yet, to see if they've discussed it.
The philosophy behind BEEP seems pretty good, even if the crazy XML style of the actual spec is not a good match (as put in an earlier email). The lack of community is worrisome, of course, but having it as an influence in our own design is probably worthwhile. I do worry about the desire not to "name" things. URIs seem so obviously a good in a system that they should be consistent for any implementation of the protocol and instance of its use. However, I recognize how much of a bite that is to chew if we don't take a substantial portion of a spec into our own that already has that defined. I'm not trying to push a REST dogma. Building a spec without RESTful design is fine by me, as long as we recognize the tradeoffs. -- Jeff On Mon, Apr 12, 2010 at 1:46 PM, Doug Cutting <cutt...@apache.org> wrote: > Jeff Hodges wrote: >> >> To throw another set of ideas into the hat, SPDY[1][2] would be good >> to learn from. SPDY takes the basics of HTTP and makes them fast. >> Benefits we would enjoy include: >> >> * Multiplexed streams >> * Request prioritization >> * HTTP header compression >> * Server push >> >> Currently in draft form. >> >> [1] http://dev.chromium.org/spdy/spdy-whitepaper >> [2] http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2 > > I like that SPDY is more actively developed than BEEP. It would be nice not > to have to re-implement clients and servers from scratch, and to perhaps > even use a pre-existing specfication. > > SPDY does fix one of the primary restrictions of HTTP in that it permits > request multiplexing: responses need not arrive in order. > > However other concerns folks have had about HTTP are that: > a. text headers are big and slow to process > b. SSL/TLS is heavyweight and inflexible for authentication > > SPDY addresses the size of headers by compressing them, but that may hinder > the speed of header processing. > > SPDY uses SSL/TLS, so would have the same issues there. Perhaps they could > be convinced to adopt SASL instead of TLS? > > Doug >
