- From: Greg Wilkins <gregw@mortbay.com>
- Date: Sat, 08 Aug 2009 15:07:52 +1000
Jonas, taking some of your comments out of order.... > My gut feeling on BWTP vs. websocket is that BWTP carries some > unneccesary complexity/overhead by allowing arbitrary headers in each > frame, whereas websocket is unnecessarily low level. I added the headers to BWTP (headers), because I didn't like the total lack of meta data in websocket. I then added virtual connections afterwards. But now you mention it, arbitrary headers in each frame is probably excessive since it could be argued that all the messages to/from a given URI are likely to have mostly same metadata so perhaps a protocol that supports virtual connections does not need per message meta data. So maybe metadata per virtual connection meta-data is sufficient? > I don't think BWTP gains a lot by using HTTP-like syntax, as I don't > think that in reality a lot of existing HTTP code can be reused. I don't think HTTP-like syntax is essential. I was just using it to start from a familiar place. It is the features that BWTP has that Websocket lacks that I think are important (plus I admit a total dislike of 0 delimited framing :). > I agree that these are very interesting features. Especially > connection multiplexing is something that I think is a good idea, for > the reasons you've mentioned elsewhere in this thread (multiple > widgets on the same page). But even compression is nice if it was > possible. Indeed it is the features that are more important ideas in BWTP rather than the syntax of the protocol. The features that I feel are important to have in the protocol are: + mime encapsulated content types (not just utf-8 and binary). + extensible content-encoding and/or transfer encoding + multiplexing + orderly close Nice to have features include: + message segmentation (good for flow when multiplexing). + intermediary participation + strict in what you generate, forgiving in what you parse + BNF style specification rather than algorithmic specification. + per message meta data > My impression is like Maciejs, that we wouldn't be able to reuse much > of our current HTTP infrastructure in order to implement BWTP. At > first glance only the header-parsing code would carry over directly, > but that's not many lines of code and so doesn't seem like a big win. Again this is valuable feedback. That's three -0' or -1's on the look-a-like-HTTP approach. I'll ponder what sort of simplifications could be made if the HTTP style is dropped. cheers
Received on Friday, 7 August 2009 22:07:52 UTC