On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <[email protected]> wrote: > On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris > <[email protected]> wrote: >> >> 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. >
So how do you build the correct type of URI from a given string? http::uri = "http://www.boost.org";; // should be valid, has URI parts smtp::uri = "http://www.boost.org";; // should be invalid, has different parts If you don't have the specific parsing (granted that the rules are very different for either type of URI) I don't see how that could be done. >> >> 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. > Cool. :) >>> 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. > No! Just rebase your current fork, and continue working on that. No need for a new fork! -- 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
