Dean Michael Berris wrote: > 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. > To be truthful I haven't even bothered to determine that. Spirit 2 was and still is for me- ambiguous. I simply chose to base that work off the boost_139 spirit docs.
> 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. > > That seems rational. Actually, after a stint of researching some Java and Python based networking libraries, I myself have come the conclusion that presenting the user with a configurable connection object for a particular protocol is preferred, in addition to a client facade for common use-cases. As a side note, I have also come to the conclusion that a mailing list is not my preferred forum for this sort of discussion, which is better suited by collaborative specifications and conferencing. I'm curious as to what the opinions of the other developers are on this. John ------------------------------------------------------------------------------ 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
