Re: [cpp-netlib-devel] Cpp-netlib Comments

[Nelson, E. - 2 <eri...@ba...>]

Dean Michael Berris wrote:

> Erik nelson wrote:
>> I had this problem as well… I just commented out the stuff I didn’t need in
>> sync_connection_base.  In my opinion a better fix is to factor
>> https_sync_connection out into a different header file that is only
>> #included if the user includes, for example, a hypothetical
>> protocol/https/client.hpp


> Well, it's not that simple you know.

It never is :)  and I know you have a lot more experience with this than me.  I'm using cpp-netlib in our production app, and just trying to put out there my experiences.

> The reason is that the URL to get/post/delete/put/head is a runtime
> value. We do some pretty clever static+runtime dispatch to determine
> whether to create an https connection object that knows how to
> establish https connections and handle the request/response
> appropriately.

That's maybe a fundamental difference in our use cases... the http/https part of the URL is *never* a runtime value for me, so there's no need for the static+runtime dispatch.  Might it be possible to factor out the dispatcher such that you have only as many dependencies as you wanted?

For example

typedef dispatcher<http> http_dispatcher;  // only handles http URLS
typedef dispatcher<https> https_dispatcher; // only handles https URLS
typedef dispatcher<https, http> https_http_dispatcher; // handles https or http URLS
typedef dispatcher<https, http, ftp> https_http_ftp_dispatcher; // handles https or http or ftp URLS

I know the names are unhandy, but at some level, dispatching is kind of an orthogonal task to what URL set is going to be used, and I don't see how it's going to be extensible to other URL types.

> The reason I opt for a macro to disable it is because I personally
> think you ought to know what you're doing with an HTTP client library
> if you specifically opt out of using SSL. The manifestation of this is
> as a macro you define that says explicitly that you don't want HTTPS
> support -- and the runtime dispatcher will just throw an exception if
> you give it an HTTPS URI.

I'd maybe argue the opposite... the https use case is more complex, with more complex dependencies, so you ought to know what you're doing if you want to *include* https support.  Plain http is about as vanilla as it gets.

> Patience is a virtue

Not intending to be impatient or complaining... whatever you decide is fine by me- you are the one doing the heavy lifting, and it totally your call.

Erik