Re: [boost] [http] Formal Review

2015-08-12 19:27 GMT-03:00 Lee Clagett :

...

Anyway - I was thinking along the same lines at various points. Having a function that pre-generates HTTP messages is very useful IMO, and should likely be included. Designing a good parsing concept would be a bit more work I think, but probably worth it too. I'm not sure how the author intends to swap out parsers in the current design. Having a fixed parser seems acceptable, but the author almost seemed to suggest that it could be selectable somehow.

A parser doesn't make sense for all communication channels.

Do you have an example of a communication channel where a parser concept wouldn't work? They wouldn't necessarily always provide the same output or behave the same way, but a communication channel has a defined format. Any implementation reading that format generally has _some_ output, which is

On Thu, Aug 13, 2015 at 11:43 AM, Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote: pretty much a parser IMO. Sorry for the bikeshedding on this, its not really necessary, but this stuck out for some reason.

Currently there is one communication channel: basic_socket<T>

basic_socket<T> is meant for embedded servers (will be extender for lean HTTP client connections in the future) and is tied to the HTTP wire format,

so it uses an HTTP parser. I don't expose the parser because I use a C

parser that is limited to the C (lack of) expressiveness. When I replace

Its possible to expose the C parser through a C++ interface, so I don't see this as a valid argument.

this parser by a better one, I'll change the situation. I don't plan to allow selectable parsers for basic_socket, but it'd be useful to select parser options (like strict parser, liberal parsers, max header size and so on...).

My apologies in the last post, I realized you just answered my question here. Your plan is no parser concepts; parsers are tied directly to a http::Socket implementation. Lee