Hey John! On Sun, Aug 16, 2009 at 6:26 PM, John P. Feltz<[email protected]> wrote: > Sorry to chime in late as always,
No worries, better late than never. ;-) > > I just dumped the in-progress work that I was doing into > http_integration_jf. This was done a number of months ago, prior to my > life-forcing break from this project. The only thing that is functional > -is the uri parser. This spirit implementation is inspired from Braden > McDaniel's uri-grammar. The gist of the design is that there was a main > class which did structural grammar checking of the url, and then a > family of re-usable grammar classes which corresponded to the http > components. To see this in action: build the tests under > libs/uri/test.For now I hope this lends some insight. I should get > around to cleaning this branch up in the near future. > Cool! Are you using Boost.Spirit 2x? I haven't been looking at these changes closely. What I've already started doing is have a base URL class from which all specific URL families (HTTP, FTP, etc.) will derive from. I've based my implementation on RFC 1738. There's a two-step parsing approach I use which first does a generic parse that parses the scheme from the scheme specific part; then invokes a 'parse_special' function that parses the scheme specific part. The basic_url<tags::default_> implementation is a bare basic_url<> that just supports the protocol(...) and rest(...) function. The specialization of the basic_url<...> for the HTTP urls is basic_url<tags::http> -- and the parsing specific to HTTP URLs is encapsulated in parse_special<traits::string<tags::http>::type, tags::http>(...). This allows anyone to create a specialization of basic_url<...> for the special parsing of FTP, "mailto", etc. Maybe we can merge the work together in a branch just for the URL parsing, then make the http_message implementation use the new URL library instead of the adhoc implementation that it's using at the moment? Personally I really want to be using Spirit 2x because I also intend to use Karma for the HTTP Message generation/encoding for MIME messages. Of course that's a lot of work down the road, but the current (not-so-well-tested) implementation seems to be able to identify between HTTP and HTTPS ports. From there we should be able to write the stuff that allows the HTTP client to create its own connections based on the protocol(http_message.url()) -- if it's "https" then use the ssl::socket and if it's just "http" use the normal tcp::socket. That needs to be ironed out and refactored into a separate logic for connection handling. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
