2009/11/8 Dean Michael Berris <[email protected]>
> Hi Glyn!
>
> On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <[email protected]>
> wrote:
> > Having said that though, I think the traits systems need to be extended,
> > because your HTTP URI can't be specialized for std::wstring (or for any
> > string which doesn't have an 8 bit character length).
> >
>
> Right...
>
> > I would suggest something along the lines of:
> >
> > namespace boost {
> > namespace network {
> > template <
> > class Tag
> > >
> > struct uri_traits {
> > typedef typename string<Tag>::type string_type;
> >
> > typedef boost::uint32_t port_type;
> >
> > static const string_type &colon() {
> > static const string_type colon = ":";
> > return colon;
> > }
> >
> > static const string_type &qmark() {
> > static const string_type qmark = "?";
> > return qmark;
> > }
> >
> > static const string_type £() {
> > static const string_type pound = "#";
> > return pound;
> > }
> > };
> >
> >
> > template <>
> > struct uri_traits<tags::wdefault> {
> > typedef string<tags::wdefault>::type string_type;
> >
> > typedef boost::uint32_t port_type;
> >
> > static const string_type &colon() {
> > static const string_type colon = L":";
> > return colon;
> > }
> >
> > static const string_type &qmark() {
> > static const string_type qmark = L"?";
> > return qmark;
> > }
> >
> > static const string_type £() {
> > static const string_type pound = L"#";
> > return pound;
> > }
> > };
> > } // namespace network
> > } // namespace boost
> >
> >
> > Do you agree with this? Unless I'm missing something, your spirit parser
> > only needs to know a small number of special delimiting characters and
> the
> > rest is generic because you then don't need to specify the string type
> > internally. I don't think this would easily extend to John's
> implementation
> > though, but his code suffers from the same problem (it uses std::string a
> > lot internally and isn't generic).
> >
>
> Yes, I like this. However, I don't want to glob the data into traits
> classes. Let's come up with some other name that's dependent on the
> tag, but is not called traits.
>
>
Are you suggesting each delimiting string be in it's own class, or just a
rename of the uri_traits class? I never intended it to be a glob, but
uri_traits is certainly the wrong name. What about uri_delimiters?
> Consequently, I'd like to see all your unit tests repeated for
> > std::wstring. I think this is important to do because it will really
> > justify the approach we are taking.
>
> I agree. Can this be done automatically? Copy-paste-replace?
>
I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
original tests so that they use template member functions:
BOOST_AUTO_TEST_CASE(my_uri_test) {
boost::network::basic_uri<tags::default_> instance;
my_uri_test_impl(instance);
}
BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
boost::network::basic_uri<tags::wstring> instance;
my_uri_test_impl(instance);
}
or something like that, it won't be difficult. But looking at that, we'll
need better names for the tags.
>
> >
> > Is there a reason why you're providing the HTTP URI under
> > boost/network/uri/http and not boost/network/protocols/http ?
> >
>
> Because I was thinking the URI library is something can be used
> externally, it's feasible that we can package it as a separate library
> to be downloaded and used in other packages. I don't mind moving it
> though, it makes sense in either location. :D
>
>
Perhaps, but as a header-only library, does this matter? As long as the
headers don't pull in unnecessary dependencies, I think it's better to keep
them grouped by protocol. I think this will be much clearer when we add
more protocols.
> > On another note, I'd like to get more involved with the development of
> the
> > URI but I'm finding it difficult to know exactly where to join, since
> there
> > are two completely different branches. For one, I'd like to add the
> wstring
> > unit tests I mentioned above (and actually some more for basic_message)
> but
> > I don't know in what branch I should because your's and John's have
> diverged
> > to a large extent. I could do this either in trunk, or in
> integration_0_4
> > but they might just end up being ignored. In fact, this is a more
> general
> > problem with the way we develop, I think, because it prevents other
> people
> > from contributing code or tests or docs. Any thoughts?
> >
>
> This bothers me a little too. I think we ought to merge the
> implementations somewhere before merging to trunk -- I haven't been
> following John's developments, but we can try and merge the tests
> first, consolidate them so that we can use different implementations
> underneath.
>
> One thing that I like doing is to keep the design and implementation
> as simple as possible -- and I really am not big on pre-design,
> because the way I do it is that I try many different things and then
> distill into an implementation that I like. I would love to make that
> process more transparent and more "a-priori". Maybe we can do a skype
> call and coordinate, I can better explain without doing any writing?
>
> What I am open to is to try a merge of the tests first -- then let's
> take approaches from one branch (from John's) and merge them into
> another branch (uri?). If you can try and do this Glyn, and and have
> everyone work on the same branch to stabilize the implementation, then
> we can work on moving in the same direction.
>
> How that that sound? (BTW, in Git this would be really "simple" to do. ;) )
>
Perhaps, but the change to Git probably shouldn't happen midway through a
development cycle. I will continue to use integration_0_4, and I'll merge
your's and John's tests. I'll try and find time to do that this coming
week.
Glyn
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
