Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

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

On Sat, Feb 20, 2010 at 12:54 AM, Nelson, Erik - 2
<eri...@ba...> wrote:
> From: Dean Michael Berris Sent: Friday, February 19, 2010 11:20 AM
>
>> Yes, even a #include is a compile-time option. This also allows you to
> define
>> the macro from the command-line of the compiler if it's allowed, or
>> from the .cpp file before >including cpp-netlib HTTP-related headers.
>
> I guess I was thinking of it another way... For example, there are lots
> of things in boost that I don't use, yet I don't need to #define any
> macros whatsoever- I simply don't include the header files.
>
> More specifically, if I want to use only the 'new' Spirit, and not the
> classic Spirit, I don't need to
>
> #define DISABLE_CLASSIC_SPIRIT
>
> I simply #include the files that have the functionality that I need.
>
> In sync_connection_base.hpp, classes https_sync_connection and
> http_sync_connection are defined.  It's not clear to me why
> http_sync_connection should require boost/asio/ssl.hpp to be included...
> if these two classes were defined in separate files (say
> https_sync_connection.hpp and http_sync_connection.hpp) couldn't we
> avoid the need to have a command-line #define to eliminate something
> that my program never requested?
>

Sure, but then that's not user friendly IMO.

I'd rather have someone do:

  #include <boost/network/include/http.hpp>

And they get both the client and the server headers and support for
HTTPS out of the box. If they don't want HTTPS support on the client
site, then that's not the full-featured HTTP client -- and you have to
say that explicitly.

Something like:

  #include <boost/network/include/http/client.hpp>
  #include <boost/network/include/http/server.hpp>

Would also be nice. Having additional includes just for explicit HTTPS
support doesn't sound like a friendly solution from my perspective.

> I'm not sure exactly how the design evolved, but I'm guessing it started
> with just http and then https was added, leading to the branching on
> 'bool https' in sync_connection_base::new_connection.
>
> I haven't looked through the code, but it feels a little like https is a
> little uncomfortable there... suppose some other transports become
> available for http, and we end up with 'httpa', 'httpb', and 'httpc'.
> It seems to me that #defining three more things that I don't want to
> use, and adding three more args to sync_connection_base::new_connection
> would feel a little strange.
>

Actually, it's meant to be scalable that way -- dynamically. And no,
there are no other protocols coming for HTTP that I know, and even if
there are, yes you'd have to turn off the features you don't want to
use. By default, to be friendly to most users who expect a
full-feature HTTP client, you enable everything.

> Anyway, this is just my viewpoint- I know you've got tons of stuff to
> do, and my parents always told me not to get in the way of the person
> doing the work.  However you decide to handle it is fine with me.
>

For now you need OpenSSL. It's not a high priority for me to implement
that macro define switch, unless you send a patch or fork the project.
;)

HTH

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