Er, note that I'm generally lightly positive on using it as a influence on the protocol, even if portions of the philosophy I find less than ideal. I mentioned the lack of community because a lack of active means whatever obstacles occur due to its fundamental nature aren't well-known and well-defined. That's reasonable, if not ideal, as we are already talking about building our own RPC! -- Jeff
On Mon, Apr 12, 2010 at 2:48 PM, Jeff Hodges <jhod...@twitter.com> wrote: > 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 >> >
