On Thu, Jun 3, 2010 at 11:16 PM, Nelson, Erik - 2 <[email protected]> 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 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
