On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris <[email protected]> wrote: > 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. >
Yes, what I meant, the new generic parser will actually do this all correctly, it now knows the difference between scheme://.. and scheme:.. and things like that, thus the new derived objects will only have to do checks like "Is the scheme actually 'http'", it won't have to do any more specific parsing. >> 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. :) > Great, I'll change them to reflect that. >> 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 > Great, I think I'll make a new fork, specifically off the 0.5-devel branch so things won't have to be merged with the master until necessary. Jeroen ------------------------------------------------------------------------------ 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
