Re: [cpp-netlib-devel] New Branch on Github

[Dean M. B. <mik...@gm...>]

On Mon, Dec 14, 2009 at 9:16 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2009/12/14 Dean Michael Berris <mik...@gm...>
>>
>>
>> Right. The request_header is definitely just a struct (or a POD). :)
>
> I think it's not a POD because it contains members that are of type
> `std::string`.
>

Hmmm... That's odd. GCC 4.4 doesn't complain with the use case. I
think this is still valid if it's not a POD because it allows for
"static" initialization. I remember std::string can be statically
initialized (as in, during compile time) which is why this works.

>>
>> I'm still thinking about moving the request/response types as nested
>> types to the http::basic_client<...> and http::server<...> instead of
>> namespace-level types, or merging them to work for both the client and
>> the server. At the worst case I would make different specializations
>> based on the tag and type-defining them as different types
>> server_request/server_response at the namespace level. I find it a
>> little ugly in the C++ world of namespaces, but if you have other
>> ideas about making the naming convention more consistent I'm all ears.
>> :D
>>
>
> Why have http::basic_client and not http::basic_server?
>

Was still thinking about that. I think I would implement an
http::basic_server if I can do something like tag dispatching based on
features to be supported by the basic_server specialization.

> I think nested classes could be a better approach, they will use the same
> tags as the server class anyway.
>

I agree. However that would break code that's already using
http::request for the client -- unless i typedef http::request to be
by default http::basic_client<...>::request which is just ugly. That
said, I think we can still afford to break backwards compatibility
because, well, we're header only --  and breaking changes will cause
users to actively upgrade their usage. <insert evil laughter here> :D

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com