Re: [cpp-netlib-devel] URI and shipping 0.4

[Glyn M. <gly...@gm...>]

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