Hi, On Sat, Jan 9, 2010 at 16:13, Dean Michael Berris <[email protected]> wrote: > On Sat, Jan 9, 2010 at 11:05 PM, Jeroen Habraken <[email protected]> wrote: >> On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris >> <[email protected]> wrote: >>> >>> Because currently the HTTP URI parses the string at construction time >>> (and URI's are immutable anyway), validity checks are as simple as >>> returning a boolean. So parse once, validity and data are available >>> right away once the object is constructed. >> >> This is indeed very nice, and should be kept this way, in what I'm >> proposing -with the exception of relative URI's, see below- will be >> kept that way, mere the place where most of the parsing is done will >> change. >> > > Alright. Let's just make sure that it does make sense and doesn't back > us into a corner. It's easy to change later on if we find that leaving > all the parsing into one parse function is too limiting (or too hard > to specialize). > >>> >>> If you are going to allow relative URI's, will that be valid for SMTP >>> too? What would be the host? >>> >> >> You're right, adding relative URI support will increase the complexity >> of the library more than I initially thought. I'm going to leave it >> out, at least for now. Implementing it later shouldn't be a problem if >> for any reason we choose to do so. >> > > If there is a good reason for us to support it then I don't have any > objection to it. Right now though I don't see it yet so I'm > apprehensive still. :) > >> >> Thank you for your thoughts, you might just have prevented me from >> overcomplicating things :) >> > > You're welcome. :) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com >
Unfortunately it's been a while since you've heard from me but I've just committed a rewrite which turns the parser into a grammar. Michael Caisse brought this up, and it allows other people to reuse the Spirit URI rule inside their own parsers. Unfortunately the transition wasn't as easy as I initially anticipated, but Hartmut Kaiser has been a great help, thanks for answering all those questions! As a bonus I've included IPv4 support, and hope to add some smaller changes such as exposing the boost::optionals soon. I've had a shot at IPv6 support, but it's an enormous rule thus it'll require some optimisation. Yours, Jeroen Habraken P.S. Dean, could you please have a look at the current derived HTTP implementation, I'd really like to hear your opinion. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
