2015-08-14 2:55 GMT-03:00 Lee Clagett
Sorry I wasn't being more clear on this - I am not advocating the buffer/view approach mentioned in the OP for HTTP, I just happened to also be thinking about protocol/messages/parsers. I thought your initial response indicated that his idea wouldn't work (it should), not that it was inefficient.
My initial response was against the complete lack of consideration to alternative HTTP backends. I was so focused on this disadvantage that I end up ignoring the socket+buffer+parser/view suggestion. In the end, it looks like OP just wants an HTTP parser. I don't even expose an HTTP parser. It'll be done in the **future**. This library is **not** an HTTP parser. You should **not** judge this library thinking it is an HTTP parser or comparing it to HTTP parsers. However, it is still interesting to compare to HTTP parsers (know I'm sure I'm looking kind of contradictory). Let me explain further: This discussion made considerations of features, limitations and use cases that showed useful to define a set of traits that can be used to make Boost.Http more useful. However, if you want an HTTP parser, you do not even care about alternative HTTP backends and this is one of the major points on Boost.Http. I won't accept features that will hamper development of alternative HTTP backends. I will, however, try to convert your suggestion to not be so detrimental, if you are willing to discuss. The buffer/view approach provided above should require a
double-parse of the HTTP header since HTTP does not define a length field at a fixed offset from the start of the message. Protocols where the length field is at a fixed offset, which indicates the entire size of the message, are better suited for that style of message handling since the first pass is pretty low CPU.
Or the parsing result could be stored into the socket object, turning the API in just a convoluted way to achieve what the message-oriented approach already provides. OTOH, you need some tricks to avoid allocations in the message-oriented approach. -- VinÃcius dos Santos Oliveira https://about.me/vinipsmaker