On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <[email protected]> wrote: > Hi guys, > > It's been a while since you've heard from me, and first of all -though > somewhat late- a Happy New Year.
Happy New Year to you too! :) > I've been reading up on the RFC and > Spirit documentation (Spirit is pure genius by the way). I'm now > working towards a full RFC compatible parser[1]. In doing so I've > found the newer RFC3986 is much more of a pleasure to work with, and > the specific HTTP parser isn't needed any more. > Okay, I hope you realize that the URI's are not just going to be for HTTP, and that we do want support FTP, SMTP, and other protocols. I don't see how you can do this without the specific parser dispatched by tag. > I've noticed a couple of things though, and I'm uncertain on how to > solve them. First of all, ports, there is the difference between the > parsed port, and the actual port to use when connecting, based on > default ports. The google-url has a port and EffectiveIntPort > function, but this information is also needed when normalising the > URI. Secondly, the parser knows the difference between no fragment, > and an empty fragment, but the current API does not expose this. Would > exposing the optional<string_type>'s be a solution? > I'd like the optional to be exposed too, that's a good idea. I've been thinking about it for a while already and I remember having that as one of the things to change. If you want to change that and the tests to reflect the new interface exposing the optional<>'s then that would be great. :) > Jeroen Habraken > > [1] This is currently not committed to git yet, I have still to > properly figure out GitHub, and fork the right branch > Actually, you can continue working on your fork and just ask me to pull when you feel like it's all fine. The fork is basically your branch from master that you maintain. I for one will keep continuing to work with 0.5-devel to implement the other tags and other client types in time for release by the end of the month. If you look at the latest (which you should rebase to) in master, it would show that I've merged the HTTP Server and HTTP 1.1 Client with chunked encoding support (as well as HTTPS). If you're familiar with Git already, then think of your fork as just another repository. Nothing special, you can do whatever you want with your repository. Once you're done making changes in your repository and want to have me integrate your changes to be the "official" release, then you send me a pull request from your master branch -- I'll take care of the merging to cpp-netlib. HTH -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
