Hi Glyn and John. On Thu, Oct 1, 2009 at 9:24 AM, John P. Feltz <[email protected]> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
