Menu
▾
▴
cpp-netlib-devel
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 00:47:56
|
Hi guys, It's been a while since you've heard from me, and first of all -though somewhat late- a Happy New Year. 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. 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? Jeroen Habraken [1] This is currently not committed to git yet, I have still to properly figure out GitHub, and fork the right branch |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 07:00:17
|
On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <vex...@gm...> 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 |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 11:59:01
|
On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <vex...@gm...> 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 |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 14:01:39
|
On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris > <mik...@gm...> 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 |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 14:21:55
|
On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris >> <mik...@gm...> 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 > The current generic URI parser will parse the string into the following structure: struct uri_parts { optional<string_type> scheme; optional<string_type> user_info optional<string_type> host optional<uint16_t> port string_type path optional<string_type> query; optional<string_type> fragment; } Note the path here may be defined as empty (thus "") by the RFC, but that's different from being omitted. The first thing to notice is, that even scheme is optional. This way we can support relative URI's like "../a/b?foo=bar", and can later support resolving an absolute and relative URI. Secondly it might make sense to parse user_info into a separate user and password, but this is not specified by the RFC. Then in uri::http you can simply check whether the URI scheme exists, and is "http" or "https", and check that a host exists (the generic parser already guarantees that if it exists it isn't empty), marking the URI invalid if these checks fail. For the uri::smtp (the format is smtp://[username@]host[:port][?options]) you simply check if the scheme is "smtp", check that a host exists (and maybe that fragment does not) and the path is empty, again marking the URI invalid if those demands aren't met. > 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! > Ok. > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 14:51:47
|
On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris > <mik...@gm...> wrote: >> >> 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 >> > > The current generic URI parser will parse the string into the > following structure: > struct uri_parts { > optional<string_type> scheme; > optional<string_type> user_info > optional<string_type> host > optional<uint16_t> port > string_type path > optional<string_type> query; > optional<string_type> fragment; > } > > Note the path here may be defined as empty (thus "") by the RFC, but > that's different from being omitted. > > The first thing to notice is, that even scheme is optional. This way > we can support relative URI's like "../a/b?foo=bar", and can later > support resolving an absolute and relative URI. Secondly it might make > sense to parse user_info into a separate user and password, but this > is not specified by the RFC. > Personally I don't see why we're going to even support relative URI's especially since we want to make request generation simple with the interface. Unless you're also going to implement a URI builder interface where you can generate "correct" URI's programmatically with C++, I don't see whether supporting relative URI's is going to be a "plus". I may not be seeing the utility of that especially for a client library. > Then in uri::http you can simply check whether the URI scheme exists, > and is "http" or "https", and check that a host exists (the generic > parser already guarantees that if it exists it isn't empty), marking > the URI invalid if these checks fail. > 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. In what you're proposing, how do you know if it's a valid URI if it's relative (if you're going to support it) and that it's also using the correct scheme (if it's omitted)? > For the uri::smtp (the format is > smtp://[username@]host[:port][?options]) you simply check if the > scheme is "smtp", check that a host exists (and maybe that fragment > does not) and the path is empty, again marking the URI invalid if > those demands aren't met. > If you are going to allow relative URI's, will that be valid for SMTP too? What would be the host? >> >> No! Just rebase your current fork, and continue working on that. No >> need for a new fork! >> > > Ok. > Thanks, looking forward to progress in this front. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 15:05:57
|
On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> 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 >>> >> >> The current generic URI parser will parse the string into the >> following structure: >> struct uri_parts { >> optional<string_type> scheme; >> optional<string_type> user_info >> optional<string_type> host >> optional<uint16_t> port >> string_type path >> optional<string_type> query; >> optional<string_type> fragment; >> } >> >> Note the path here may be defined as empty (thus "") by the RFC, but >> that's different from being omitted. >> >> The first thing to notice is, that even scheme is optional. This way >> we can support relative URI's like "../a/b?foo=bar", and can later >> support resolving an absolute and relative URI. Secondly it might make >> sense to parse user_info into a separate user and password, but this >> is not specified by the RFC. >> > > Personally I don't see why we're going to even support relative URI's > especially since we want to make request generation simple with the > interface. > > Unless you're also going to implement a URI builder interface where > you can generate "correct" URI's programmatically with C++, I don't > see whether supporting relative URI's is going to be a "plus". I may > not be seeing the utility of that especially for a client library. > >> Then in uri::http you can simply check whether the URI scheme exists, >> and is "http" or "https", and check that a host exists (the generic >> parser already guarantees that if it exists it isn't empty), marking >> the URI invalid if these checks fail. >> > > 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. > In what you're proposing, how do you know if it's a valid URI if it's > relative (if you're going to support it) and that it's also using the > correct scheme (if it's omitted)? > >> For the uri::smtp (the format is >> smtp://[username@]host[:port][?options]) you simply check if the >> scheme is "smtp", check that a host exists (and maybe that fragment >> does not) and the path is empty, again marking the URI invalid if >> those demands aren't met. >> > > 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. >>> >>> No! Just rebase your current fork, and continue working on that. No >>> need for a new fork! >>> >> >> Ok. >> > > Thanks, looking forward to progress in this front. ;) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Thank you for your thoughts, you might just have prevented me from overcomplicating things :) Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 15:13:53
|
On Sat, Jan 9, 2010 at 11:05 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris > <mik...@gm...> 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 |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 20:28:29
|
Hi, On Sat, Jan 9, 2010 at 16:13, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 11:05 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris >> <mik...@gm...> 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. |
|
From: Glyn M. <gly...@gm...> - 2010-02-04 21:13:48
|
Hi Jeroen, On 4 February 2010 21:27, Jeroen Habraken <vex...@gm...> wrote: > > 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. > > Excellent, thank you very much for this effort. I will take a closer look when I find time and will provide feedback later. Glyn |
|
From: Dean M. B. <mik...@gm...> - 2010-02-06 08:48:24
|
Hi Jeroen, On Fri, Feb 5, 2010 at 4:27 AM, Jeroen Habraken <vex...@gm...> wrote: > > 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. No worries. I'm looking at it right now and I'm having some trouble merging to my local copy. I'll resolve issues locally first then see if I can merge your implementation to master, and then pull it from my 0.6-devel branch. > 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! > Cool. They're a great bunch of guys there at the Spirit Mailing list. :) > 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. > Sweet! We can worry about IPv6 later when the world starts catching up and implementing it as the default instead of IPv4. :) > 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. > I'll let you know if I find any glaring problems. Have a good day and you'd hopefully hear more from me soon. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-02-06 23:14:36
|
Hi Dean, On Sat, Feb 6, 2010 at 09:47, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen, > > On Fri, Feb 5, 2010 at 4:27 AM, Jeroen Habraken <vex...@gm...> wrote: >> >> 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. > > No worries. I'm looking at it right now and I'm having some trouble > merging to my local copy. I'll resolve issues locally first then see > if I can merge your implementation to master, and then pull it from my > 0.6-devel branch. > >> 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! >> > > Cool. They're a great bunch of guys there at the Spirit Mailing list. :) > >> 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. >> > > Sweet! We can worry about IPv6 later when the world starts catching up > and implementing it as the default instead of IPv4. :) > >> 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. >> > > I'll let you know if I find any glaring problems. > > Have a good day and you'd hopefully hear more from me soon. :) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > I saw you've merged my changes to master, yet I'd have preferred if you had waited for my pull request. I intended to add the boost::optional changes to the API first, to catch the breaking in one go, yet I'm honoured that you considered my code to be master-branch ready. Unfortunately with the merge you've reintroduced issue #3, something I hadn't patched as I was anticipating to merge upstream with my code before a pull-request. I've now merged upstream with my fork and issued a pull-request to fix this in the 0.6-devel branch, but it should be merged with master too. I'll also try to layout somewhat of roadmap for the URI code as some of the things I've mentioned before still have to be done: - A lot more tests need to be added - Documentation needs to be updated, and an the example should be expanded to show the use of scheme() for example - Another API change is coming up, which will expose the optional parameters as boost::optionals, instead of returning an empty default value On the longer term I'd like to get on the way with URI normalisation, but it still needs some pondering on how this will fit in the current code. Given the fact that 0.6 is planned for the end of February, my initial plan would be to finish what I'd hoped to do for 0.5, namely the three things above. Yours, Jeroen Habraken |
|
From: Dean M. B. <mik...@gm...> - 2010-02-09 17:10:45
|
Hi Jeroen, I apologize for not being able to respond to the list sooner, I've been busy between being father, husband, and part-time consultant+project manager lately. That said I try to keep on top of emails, and I've only been able to relax a bit now. Hopefully I'll be able to respond to emails quicker this time. That said please see below. On Sun, Feb 7, 2010 at 7:14 AM, Jeroen Habraken <vex...@gm...> wrote: > > I saw you've merged my changes to master, yet I'd have preferred if > you had waited for my pull request. I intended to add the > boost::optional changes to the API first, to catch the breaking in one > go, yet I'm honoured that you considered my code to be master-branch > ready. > Yup, no worries. That merge also included a few fixes in different places. I actually wasn't supposed to merge with master, but I was having some trouble merging to 0.6-devel directly, having your code branched from 0.5-devel. I decided since I've already merged 0.5-devel to master, I might as well merge your code to master. ;) > Unfortunately with the merge you've reintroduced issue #3, something I > hadn't patched as I was anticipating to merge upstream with my code > before a pull-request. I've now merged upstream with my fork and > issued a pull-request to fix this in the 0.6-devel branch, but it > should be merged with master too. > Yup, I overlooked this. Thanks for patching and catching that. We should have a test for that specific issue! :D (That said I think I've merged it already into head and 0.6-devel too). ;) > I'll also try to layout somewhat of roadmap for the URI code as some > of the things I've mentioned before still have to be done: > - A lot more tests need to be added +1 > - Documentation needs to be updated, and an the example should be > expanded to show the use of scheme() for example +1 > - Another API change is coming up, which will expose the optional > parameters as boost::optionals, instead of returning an empty default > value > +1 > On the longer term I'd like to get on the way with URI normalisation, > but it still needs some pondering on how this will fit in the current > code. Given the fact that 0.6 is planned for the end of February, my > initial plan would be to finish what I'd hoped to do for 0.5, namely > the three things above. > That sounds great. Please branch off of 0.6-devel this time so that further development takes advantage of the new stuff I'll be checking in sooner than later. I really should stop being project manager and just get back to engineer mode both in cpp-netlib and in my consulting gigs. I miss writing C++!!! :D > Yours, > Jeroen Habraken > Thanks again for all the work, I think I personally don't have the patience to deal with the intricacies of being RFC compliant at the URI layer unlike you and other contributors to the project. Have a good week ahead and I look forward to another pull request soon! :D -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X