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

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

On Thu, Jun 3, 2010 at 11:16 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
> Dean Michael Berris wrote:
>
>> 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.
>

That's good to know, cpp-netlib is in production somewhere! :D

>> 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.

Well, actually, it kinda is a runtime value for everyone using cpp-netlib.

Even if it's hard-coded (the URL), it still has to be parsed at
runtime. That means, at compile-time, there's no way for the library
to know from a type standpoint that the URI is an HTTP or HTTPS URI.
This is the reason there's a mix of static and runtime dispatch --
static dispatch for the tags, runtime dispatch for determining whether
it's HTTP or HTTPS.

> 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.
>

If you look at the way the dispatch happens, it's really simple: if
it's an "https://..." then create an instance of an
https_sync_connection object and get a handle to it using a reference
to a sync_connection_base (the virtual base type). This is purely
dynamic dispatch, no need for a layer for dispatching. :)

It's the factory+strategy patterns combined, only the factory is
static while the strategy is dynamic. :D

>> 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.
>

That makes sense, but then I would solve it using macro's still --
adding a different header to include just HTTP is just wasteful IMO. I
may be convinced otherwise, and as you know patches/pull-requests are
totally welcome. :D

>> 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.
>

That's alright, my version of the fix is already up in the 0.7-devel branch. :)

-- 
Dean Michael Berris
deanberris.com