Menu
▾
▴
cpp-netlib-devel
|
From: Glyn M. <gly...@gm...> - 2009-09-30 19:26:58
|
Hi netlibers, I'd like to ask everyone who's working on something for C++ Networking Library to give me a status update. I notice that some work is being done ondifferent branches and I'm a little concerned that there's duplicate effort going on, specifically for URI processing (I think there are at least 3 or 4 different implementations of URI parsers in various stages of completion). A couple of months ago Dean suggested we start thinking about getting version 0.4 out of the door and I'd like to coordinate our efforts on this, and to release a reasonable quality, generic URI in the near future, so then we can concentrate on improvements and protocol implementations after that. References: https://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements Thanks, Glyn |
|
From: John P. F. <jf...@ov...> - 2009-10-01 02:44:08
|
I'm glad you posted the link, this basically is the first step of what needs to be decided upon for completion of this feature. I think my implementation is close in addressing the proposed requirements. At the moment it's lacking relative resolution and grammar from 1.1 (it's based off the 1.0 rfc, I think the differences are minor at the moment). I'm desiring an extensible uri parsing solution. While it is a bit of a departure from the the original protocol objectives of the library, It doesn't veer off too far as to become needless and wasteful. Nevertheless, I'm trying not to argue use of my implementation over another. The question is ultimately, if the requirements are common. If not, than there are clear reasons to back a particular implementation. John Glyn Matthews wrote: > Hi netlibers, > > > I'd like to ask everyone who's working on something for C++ Networking > Library to give me a status update. I notice that some work is being done > ondifferent branches and I'm a little concerned that there's duplicate > effort going on, specifically for URI processing (I think there are at least > 3 or 4 different implementations of URI parsers in various stages of > completion). > > A couple of months ago Dean suggested we start thinking about getting > version 0.4 out of the door and I'd like to coordinate our efforts on this, > and to release a reasonable quality, generic URI in the near future, so then > we can concentrate on improvements and protocol implementations after that. > > References: > https://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements > > Thanks, > Glyn > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ------------------------------------------------------------------------ > > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > |
|
From: Glyn M. <gly...@gm...> - 2009-10-01 07:12:18
|
Hi John, 2009/10/1 John P. Feltz <jf...@ov...> > I'm glad you posted the link, this basically is the first step of what > needs to be decided upon for completion of this feature. Thanks for doing this. > I think my > implementation is close in addressing the proposed requirements. At the > moment it's lacking relative resolution and grammar from 1.1 (it's based > off the 1.0 rfc, I think the differences are minor at the moment). I'm > desiring an extensible uri parsing solution. While it is a bit of a > departure from the the original protocol objectives of the library, It > doesn't veer off too far as to become needless and wasteful. > Nevertheless, I'm trying not to argue use of my implementation over > another. The question is ultimately, if the requirements are common. If > not, than there are clear reasons to back a particular implementation. > > The first issue with choosing one implementation over another is that we have 3 and each has a different set of unit tests. Each can be found here: https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/uri/libs/network/test/uri_test.cpp https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/urllib-dean/libs/network/test/url_test.cpp https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/http_integration_jf/libs/uri/test/rfc3986_spirit_grammar.cpp This suggests that everyone is working towards different goals, and the first thing we should do is gather our unit tests so we can agree on what we expect from a URI interface. I think Dean's approach is biased towards HTTP (I think he intends to add types to support e.g. smtp::uri, xmpp::uri etc. in the same way as he wants to extend the request and response templates) and John's is aiming towards matching the RFC specs as close as possible. Is this a fair analysis? G |
|
From: John P. F. <jf...@ov...> - 2009-10-01 18:34:57
|
Glyn Matthews wrote: > https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/http_integration_jf/libs/uri/test/rfc3986_spirit_grammar.cpp > > Is this a fair analysis? > > G > > I won't have time to look at others for points of compromise, debate, or try to convey the merits of my approach until next weekend. But at the very least, I ask that the following be looked at, as it is not simply a set of grammar: http_integration_jf/libs/network/test/http_uri_parse.cpp Essentially the design comes together here. Speaking of 3986, against my desire to remove it-as the grammar is currently not used by HTTP (at least not officially, due to it being so new), I've left it more for reference value, rather than anything practical. John |
|
From: Dean M. B. <mik...@gm...> - 2009-10-01 15:20:18
|
Hi Glyn and John. On Thu, Oct 1, 2009 at 9:24 AM, John P. Feltz <jf...@ov...> wrote: > I'm glad you posted the link, this basically is the first step of what > needs to be decided upon for completion of this feature. I think my > implementation is close in addressing the proposed requirements. I agree. > At the moment it's lacking relative resolution and grammar from 1.1 (it's based > off the 1.0 rfc, I think the differences are minor at the moment). I'm > desiring an extensible uri parsing solution. While it is a bit of a > departure from the the original protocol objectives of the library, It > doesn't veer off too far as to become needless and wasteful. > Nevertheless, I'm trying not to argue use of my implementation over > another. The question is ultimately, if the requirements are common. If > not, than there are clear reasons to back a particular implementation. > I think we can merge the parsers you've built that are closer to the RFC within the higher level interface that I intend to provide with my URL implementation. Extensibility is a matter of design, and the approach I've taken is to have specific points of extension where different -- and new -- URI implementations can be provided. I don't believe there is a one-size-fits-all design for the implementation, and although the dynamic nature of runtime-generated URI's may require a dynamic solution (with *ghasp* runtime virtual inheritance). This is only though if you want to have a URI implementation that can stand on its own outside of cpp-netlib; where my focus has been for type safety on a per-protocol basis -- having 'http::uri', 'smtp::uri', or 'ftp::uri' classes and have clear, type-safe, conversion functions from a 'uri::uri' to the more specific type. > > Glyn Matthews wrote: >> Hi netlibers, >> >> >> I'd like to ask everyone who's working on something for C++ Networking >> Library to give me a status update. I notice that some work is being done >> ondifferent branches and I'm a little concerned that there's duplicate >> effort going on, specifically for URI processing (I think there are at least >> 3 or 4 different implementations of URI parsers in various stages of >> completion). >> >> A couple of months ago Dean suggested we start thinking about getting >> version 0.4 out of the door and I'd like to coordinate our efforts on this, >> and to release a reasonable quality, generic URI in the near future, so then >> we can concentrate on improvements and protocol implementations after that. >> Thanks Glyn for doing this. I can only post the user-level API that I expect to provide, which is shown in the direction that I took when I wrote the unit tests on my branch. I think we can definitely merge John's parsers and more RFC-compliant implementation into my approach. >> References: >> https://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements >> Should I put the high-level API description in this page too? Thanks again guys and I hope this helps. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Kim G. <kim...@gm...> - 2009-10-01 04:49:53
|
Hi Glyn, On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...> wrote: > > I'd like to ask everyone who's working on something for C++ Networking > Library to give me a status update. I notice that some work is being done > ondifferent branches and I'm a little concerned that there's duplicate > effort going on, specifically for URI processing (I think there are at least > 3 or 4 different implementations of URI parsers in various stages of > completion). I've abandoned my part in that, so we might as well kill off the uri branch (I hope that was where I was mucking about). I just yesterday got cpp-netlib building on my new laptop after a 9-month hiatus. - Kim |
|
From: Glyn M. <gly...@gm...> - 2009-10-01 08:03:40
|
Hi Kim, 2009/10/1 Kim Gräsman <kim...@gm...> > Hi Glyn, > > On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...> > wrote: > > I've abandoned my part in that, so we might as well kill off the uri > branch (I hope that was where I was mucking about). I just yesterday > got cpp-netlib building on my new laptop after a 9-month hiatus. > > - Kim > Thanks for the update Are you still interested in contributing to the URI? G |
|
From: Kim G. <kim...@gm...> - 2009-10-01 09:37:23
|
Hi Glyn, On Thu, Oct 1, 2009 at 10:03, Glyn Matthews <gly...@gm...> wrote: > > 2009/10/1 Kim Gräsman <kim...@gm...> >> >> On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...> >> wrote: >> >> I've abandoned my part in that, so we might as well kill off the uri >> branch (I hope that was where I was mucking about). I just yesterday >> got cpp-netlib building on my new laptop after a 9-month hiatus. >> > > Thanks for the update Are you still interested in contributing to the URI? Yeah, but not actively, I don't have all that much free time at the moment. I'll chip in with test cases and surly remarks if I stumble over something :) - Kim |
|
From: John P. F. <jf...@ov...> - 2009-10-01 18:38:43
|
Dean Michael Berris wrote: > > Should I put the high-level API description in this page too? > > Thanks again guys and I hope this helps. > Design spec. John |
|
From: Dean M. B. <mik...@gm...> - 2009-10-02 14:47:46
|
On Fri, Oct 2, 2009 at 2:38 AM, John P. Feltz <jf...@ov...> wrote: > > > Dean Michael Berris wrote: >> >> Should I put the high-level API description in this page too? >> >> Thanks again guys and I hope this helps. >> > Design spec. > Ah, okay. I'll look for the document in the Wiki. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis 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