Re: [boost] [http] Formal Review

Subject: Re: [boost] [http] Formal Review
From: Lee Clagett (forum_at_[hidden])
Date: 2015-08-13 21:29:27

On Thu, Aug 13, 2015 at 11:43 AM, Vinícius dos Santos Oliveira <
vini.ipsmaker_at_[hidden]> wrote:

> 2015-08-12 19:27 GMT-03:00 Lee Clagett <forum_at_[hidden]>:
>
> > 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
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