Menu
▾
▴
cpp-netlib-devel
|
From: Dean M. B. <mik...@gm...> - 2009-11-06 16:57:14
|
Hi Guys, After a few months of being stressed anticipating a child -- who has now been born into the world -- I finally am a father and also finding myself more motivated to get cpp-netlib going. I've made some changes to the urllib-dean branch and have changed the parsers to better follow the RFCs -- although I've only parsed the HTTP URIs. Please take a look and see if you find anything glaring that I should address. PS. Is it time for us to use Git instead of Subversion? Tracking branches by John and me and then maybe in the future merging into a single branch may be a pain with Subversion -- although I haven't tried yet. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-11-06 18:03:46
|
Hi Dean, 2009/11/6 Dean Michael Berris <mik...@gm...> > Hi Guys, > > After a few months of being stressed anticipating a child -- who has > now been born into the world -- I finally am a father and also finding > myself more motivated to get cpp-netlib going. > First things first: congratulations! that's fantastic news. > > I've made some changes to the urllib-dean branch and have changed the > parsers to better follow the RFCs -- although I've only parsed the > HTTP URIs. > > Please take a look and see if you find anything glaring that I should > address. > > I will take some time this weekend to take a look. > PS. Is it time for us to use Git instead of Subversion? Tracking > branches by John and me and then maybe in the future merging into a > single branch may be a pain with Subversion -- although I haven't > tried yet. > > +1 I am beginning to be won over by Git. Glyn |
|
From: Dean M. B. <mik...@gm...> - 2009-11-06 18:17:06
|
Hi Glyn! On Sat, Nov 7, 2009 at 2:03 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > 2009/11/6 Dean Michael Berris <mik...@gm...> >> >> Hi Guys, >> >> After a few months of being stressed anticipating a child -- who has >> now been born into the world -- I finally am a father and also finding >> myself more motivated to get cpp-netlib going. > > First things first: congratulations! that's fantastic news. Thanks! :) >> >> I've made some changes to the urllib-dean branch and have changed the >> parsers to better follow the RFCs -- although I've only parsed the >> HTTP URIs. >> >> Please take a look and see if you find anything glaring that I should >> address. >> > I will take some time this weekend to take a look. > Thanks Glyn. :) > >> >> PS. Is it time for us to use Git instead of Subversion? Tracking >> branches by John and me and then maybe in the future merging into a >> single branch may be a pain with Subversion -- although I haven't >> tried yet. >> > +1 I am beginning to be won over by Git. > Sweet. Now we just need a transition plan. Also, I'm liking github a lot, but then Sourceforge has been good to us through the years. ;) I think if John feels like Git is the way to go (since apparently we're the only three active developers at the moment) then we might as well switch to pure Git soon. ;) Also, I plan to make a presentation about cpp-netlib at BoostCon 2010 -- it would be great if we can get a 1.0 out before February 2010 so that we'll have a presentation ready by then. :D -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: John P. F. <jf...@ov...> - 2009-11-06 20:57:07
|
I don't see any compelling reason for either git vs svn or sf vs github. I only see a time cost that would be better spent on actually improving the library. Merging in SVN from what I've seen is fairly trivial, it is the design decisions that are hard -and those can be addressed through work on the specs and subsequent division between Dean and myself (currently). John Dean Michael Berris wrote: > Hi Glyn! > > On Sat, Nov 7, 2009 at 2:03 AM, Glyn Matthews <gly...@gm...> wrote: > >> Hi Dean, >> >> 2009/11/6 Dean Michael Berris <mik...@gm...> >> >>> Hi Guys, >>> >>> After a few months of being stressed anticipating a child -- who has >>> now been born into the world -- I finally am a father and also finding >>> myself more motivated to get cpp-netlib going. >>> >> First things first: congratulations! that's fantastic news. >> > > Thanks! :) > > >>> I've made some changes to the urllib-dean branch and have changed the >>> parsers to better follow the RFCs -- although I've only parsed the >>> HTTP URIs. >>> >>> Please take a look and see if you find anything glaring that I should >>> address. >>> >>> >> I will take some time this weekend to take a look. >> >> > > Thanks Glyn. :) > > >>> PS. Is it time for us to use Git instead of Subversion? Tracking >>> branches by John and me and then maybe in the future merging into a >>> single branch may be a pain with Subversion -- although I haven't >>> tried yet. >>> >>> >> +1 I am beginning to be won over by Git. >> >> > > Sweet. Now we just need a transition plan. Also, I'm liking github a > lot, but then Sourceforge has been good to us through the years. ;) > > I think if John feels like Git is the way to go (since apparently > we're the only three active developers at the moment) then we might as > well switch to pure Git soon. ;) > > Also, I plan to make a presentation about cpp-netlib at BoostCon 2010 > -- it would be great if we can get a 1.0 out before February 2010 so > that we'll have a presentation ready by then. :D > > |
|
From: Dean M. B. <mik...@gm...> - 2009-11-08 17:38:47
|
Hi John, On Fri, Nov 6, 2009 at 8:56 PM, John P. Feltz <jf...@ov...> wrote: > I don't see any compelling reason for either git vs svn or sf vs github. > I only see a time cost that would be better spent on actually improving > the library. Merging in SVN from what I've seen is fairly trivial, it is > the design decisions that are hard -and those can be addressed through > work on the specs and subsequent division between Dean and myself > (currently). > I am not sure where the division is though. What I have stated before about how to go forward has been clear in both my mind and the code I've written. The tests are the specification for what features I'm looking for in a header-only URI library. The idea is to keep it simple. I like code that looks like the following: uri instance = "http://www.boost.org/"; assert(scheme(instance) == "http"); http::uri http_instance = instance; assert(valid(http_instance)); assert(host(http_instance) == "www.boost.org"); The HttpURI and URI concepts are now documented with BCCL and enforced at compile time too. As far as design goes, I expect any URI to be default constructible, swappable, and convertible to and from a basic_uri<default>. Now the parsing implementation boils down to which one adheres to the RFC more, and which has a more "simple" implementation. Simple is a matter of taste, but it also means succinct and maintainable. Do you have any specific questions that I can address in case there haven't been any formal design documentation in place yet anywhere? I must apologize for not ever having to write one (and not ever feeling like I would have to write one just for cpp-netlib ;) ) because I really don't know how to write a design document. Let me know how I can close the division from my end. HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: John P. F. <jf...@ov...> - 2009-11-09 21:56:03
|
Dean Michael Berris wrote: > Hi John, > > On Fri, Nov 6, 2009 at 8:56 PM, John P. Feltz <jf...@ov...> wrote: > >> I don't see any compelling reason for either git vs svn or sf vs github. >> I only see a time cost that would be better spent on actually improving >> the library. Merging in SVN from what I've seen is fairly trivial, it is >> the design decisions that are hard -and those can be addressed through >> work on the specs and subsequent division between Dean and myself >> (currently). >> >> > > I am not sure where the division is though. What I have stated before > about how to go forward has been clear in both my mind and the code > I've written. The tests are the specification for what features I'm > looking for in a header-only URI library. > Testing code is fine, however among other benefits, a document is easier to use for reaching consensus prior to coding (a much more laborious process without that). > Let me know how I can close the division from my end. > I was referring to the benefit of a clear division of labor that documents and people help establish. John |
|
From: Allister L. S. <all...@gm...> - 2009-11-06 18:42:22
|
Dean, Congratulations! Enjoy the sleepless nights heheheh On Fri, Nov 6, 2009 at 5:57 PM, Dean Michael Berris <mik...@gm...>wrote: > Hi Guys, > > After a few months of being stressed anticipating a child -- who has > now been born into the world -- I finally am a father and also finding > myself more motivated to get cpp-netlib going. > > |
|
From: Glyn M. <gly...@gm...> - 2009-11-07 11:53:01
|
2009/11/6 Dean Michael Berris <mik...@gm...> > > >> PS. Is it time for us to use Git instead of Subversion? Tracking > >> branches by John and me and then maybe in the future merging into a > >> single branch may be a pain with Subversion -- although I haven't > >> tried yet. > >> > > +1 I am beginning to be won over by Git. > > > > >> > Sweet. Now we just need a transition plan. Also, I'm liking github a > lot, but then Sourceforge has been good to us through the years. ;) > We can use Git with sourceforge, that's not a problem. I know that a Trac plugin exists for Git and that there a plenty of tools available for switching between git and SVN so maybe we can do this without a lot of disruption. > > Also, I plan to make a presentation about cpp-netlib at BoostCon 2010 > -- it would be great if we can get a 1.0 out before February 2010 so > that we'll have a presentation ready by then. :D > That's really interesting. What do you propose to talk about? Glyn |
|
From: Glyn M. <gly...@gm...> - 2009-11-08 11:40:18
|
2009/11/6 Glyn Matthews <gly...@gm...>
>
> 2009/11/6 Dean Michael Berris <mik...@gm...>
>
>>
>> I've made some changes to the urllib-dean branch and have changed the
>> parsers to better follow the RFCs -- although I've only parsed the
>> HTTP URIs.
>>
>> Please take a look and see if you find anything glaring that I should
>> address.
>>
>> I will take some time this weekend to take a look.
>
>
You've defined new tags and traits classes in boost/network/uri/tags.hpp and
boost/network/uri/traits/* Why is this? These are identical to those found
in boost/network/message/tags.hpp and boost/network/message/traits/*.
Surely they don't need to be repeated?
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).
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).
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.
Is there a reason why you're providing the HTTP URI under
boost/network/uri/http and not boost/network/protocols/http ?
Otherwise I like the progress you're making, it is taking good shape.
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?
Glyn
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-08 17:18:30
|
Hi Glyn!
On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <gly...@gm...> wrote:
> 2009/11/6 Glyn Matthews <gly...@gm...>
>
> You've defined new tags and traits classes in boost/network/uri/tags.hpp and
> boost/network/uri/traits/* Why is this? These are identical to those found
> in boost/network/message/tags.hpp and boost/network/message/traits/*.
> Surely they don't need to be repeated?
>
Oh, you're right. :) I didn't notice that. ;)
> 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.
> 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?
>
> 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
> Otherwise I like the progress you're making, it is taking good shape.
>
Thanks!
> 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. ;) )
--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-08 17:27:23
|
Hi Glyn!
On Sat, Nov 7, 2009 at 7:52 PM, Glyn Matthews <gly...@gm...> wrote:
>
>
> 2009/11/6 Dean Michael Berris <mik...@gm...>
>>
>> >> PS. Is it time for us to use Git instead of Subversion? Tracking
>> >> branches by John and me and then maybe in the future merging into a
>> >> single branch may be a pain with Subversion -- although I haven't
>> >> tried yet.
>> >>
>> > +1 I am beginning to be won over by Git.
>> >
>>
>> >>
>> Sweet. Now we just need a transition plan. Also, I'm liking github a
>> lot, but then Sourceforge has been good to us through the years. ;)
>
> We can use Git with sourceforge, that's not a problem. I know that a Trac
> plugin exists for Git and that there a plenty of tools available for
> switching between git and SVN so maybe we can do this without a lot of
> disruption.
Nice! Yes, this is what I was thinking, we can use the Git hosting
from Sourceforge -- and then integrate changes from Git to SVN trunk,
for people still tracking the SVN repository.
>>
>> Also, I plan to make a presentation about cpp-netlib at BoostCon 2010
>> -- it would be great if we can get a 1.0 out before February 2010 so
>> that we'll have a presentation ready by then. :D
>
> That's really interesting. What do you propose to talk about?
>
Once we have an implementation out that's ready for general user
consumption, I plan to really do a "media blitz" at some point next
year (starting with BoostCon) to get people interested in the project
to try it out and let us developers what they think. A DDJ article
wouldn't help too, and more blog exposure would be nice to have.
One of the things I'd like to talk about is the way we're going about
the header-only approach to implementing an "embeddable" HTTP client.
So far nothing out there is like what we have (even in its most
primitive but functional form) because what we do offer is a really
simple and flexible way of letting users create HTTP requests through
the client abstraction. Even Python libraries are very heavy
especially if you want to do anything more complex than pulling a web
page. The MFC and .NET library for network programming (with HTTP) are
just horribly clumsy and unwieldy for any beginner or developer not
really writing a web browser.
At some point I would like to see cpp-netlib graduate into Boost, and
continue developing network-specific implementations separately, keep
improving, and somehow be a basis for a proposal to be part of the
next C++ standard library.
Wouldn't it be cool to have C++ programs be able to pull a webpage by
just doing:
http::client c;
http::response r = c.get("http://www.boost.org/");
A non-throwing version would look like:
http::client c;
http::response r;
system::error_code e;
tie(r,e) = c.get("http://www.boost.org/", http::nothrow);
? :D
HTH
--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Glyn M. <gly...@gm...> - 2009-11-08 21:20:12
|
2009/11/8 Dean Michael Berris <mik...@gm...> > On Sat, Nov 7, 2009 at 7:52 PM, Glyn Matthews <gly...@gm...> > wrote: > > 2009/11/6 Dean Michael Berris <mik...@gm...> > > > > We can use Git with sourceforge, that's not a problem. I know that a > Trac > > plugin exists for Git and that there a plenty of tools available for > > switching between git and SVN so maybe we can do this without a lot of > > disruption. > > > Nice! Yes, this is what I was thinking, we can use the Git hosting > from Sourceforge -- and then integrate changes from Git to SVN trunk, > for people still tracking the SVN repository. > > Yeah, I'll do this once we've merged the URI to trunk and released 0.4. > >> > >> Also, I plan to make a presentation about cpp-netlib at BoostCon 2010 > >> -- it would be great if we can get a 1.0 out before February 2010 so > >> that we'll have a presentation ready by then. :D > > > > That's really interesting. What do you propose to talk about? > > > > Once we have an implementation out that's ready for general user > consumption, I plan to really do a "media blitz" at some point next > year (starting with BoostCon) to get people interested in the project > to try it out and let us developers what they think. A DDJ article > wouldn't help too, and more blog exposure would be nice to have. > A DDJ article *would* help ;) The blog at blogspot has way too much spam in the comments, making it ineffective because we can't get feedback. If you feel like adding a new post describing progress, you should do so. More community exposure is necessary for progress. Also there is an ohloh account: http://www.ohloh.net/p/cpp-netlib > > One of the things I'd like to talk about is the way we're going about > the header-only approach to implementing an "embeddable" HTTP client. > So far nothing out there is like what we have (even in its most > primitive but functional form) because what we do offer is a really > simple and flexible way of letting users create HTTP requests through > the client abstraction. Even Python libraries are very heavy > especially if you want to do anything more complex than pulling a web > page. The MFC and .NET library for network programming (with HTTP) are > just horribly clumsy and unwieldy for any beginner or developer not > really writing a web browser. > > At some point I would like to see cpp-netlib graduate into Boost, and > continue developing network-specific implementations separately, keep > improving, and somehow be a basis for a proposal to be part of the > next C++ standard library. > > Wouldn't it be cool to have C++ programs be able to pull a webpage by > just doing: > > http::client c; > http::response r = c.get("http://www.boost.org/"); > > A non-throwing version would look like: > > http::client c; > http::response r; > system::error_code e; > tie(r,e) = c.get("http://www.boost.org/", http::nothrow); > > ? :D > > std::nothrow? But yes, this looks good :) G |
|
From: Glyn M. <gly...@gm...> - 2009-11-08 21:21:35
|
2009/11/8 Dean Michael Berris <mik...@gm...>
> Hi Glyn!
>
> On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <gly...@gm...>
> 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
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-09 13:02:50
|
Hi Glyn!
On Mon, Nov 9, 2009 at 5:21 AM, Glyn Matthews <gly...@gm...> wrote:
>
>
> 2009/11/8 Dean Michael Berris <mik...@gm...>
>>
[snip]
>>
>> 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?
>
I would want to move them into one class each -- that way in case we
need to add more 'constants' we don't change a globbed together class
that easily grows and becomes unweildy -- also, it also allows us to
re-use these in other contexts. It doesn't hurt to have them
individually in different classes either, except maybe the duplication
of opening and closing braces. ;)
I would make a namespace which contains the delimiters, something like
'boost::network::uri::detail::delimeters' and have each class named
appropriately like 'detail::delimeters::colon<Tag>::char_()' or
'detail::delimeters::question_mark<Tag>::char_()'.
For the first try though if you'd like to implement it with a single
'delimeters' type with a tag and then call the static functions by
name like 'detail::delimeters<Tag>::question_mark()', please be my
guest. Changing later on should not be a problem since it's an
implementation detail. ;)
>> > 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.
I agree. Would you make it happen and let me know so that I can pull
your changes? :D
>>
>> >
>> > 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.
>
Yeah, I guess. Feel free to move them around -- also let me know when
it's done so that I can pull your changes. :D
>>
>> 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.
>
Sounds great Glyn, thanks for taking this on!
--
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-11-09 06:09:41
|
Hi guys,
On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...> wrote:
>
>> > 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.
For the xUnit, OO-style, test frameworks there's a pattern called
Abstract Test Case, where all test methods reside in a base class,
together with one or more abstract methods denoting variance. Then you
create derived, concrete classes that implement the variations for the
specific types, and the runner sees them as separate suites.
That's essentially what you're describing above, except you would have
to repeat every test case for every variation.
I wonder if there's a way to use Boost.Test fixtures to implement
Abstract Test Case with a type variation...?
- Kim
|
|
From: Glyn M. <gly...@gm...> - 2009-11-09 08:31:31
|
Hi Kim,
2009/11/9 Kim Gräsman <kim...@gm...>
> Hi guys,
>
> On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...>
> wrote:
> >
> >> > 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.
>
> For the xUnit, OO-style, test frameworks there's a pattern called
> Abstract Test Case, where all test methods reside in a base class,
> together with one or more abstract methods denoting variance. Then you
> create derived, concrete classes that implement the variations for the
> specific types, and the runner sees them as separate suites.
>
> That's essentially what you're describing above, except you would have
> to repeat every test case for every variation.
>
> I wonder if there's a way to use Boost.Test fixtures to implement
> Abstract Test Case with a type variation...?
>
>
This seems to be the recommended usage pattern for testing generic
components with different template patterns:
http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/generic.html#id663542
Thanks,
Glyn
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-09 13:11:06
|
On Mon, Nov 9, 2009 at 4:31 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Kim,
>
> 2009/11/9 Kim Gräsman <kim...@gm...>
>>
>> Hi guys,
>>
>> On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...>
>> wrote:
>> >
>> >> > 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.
>>
>> For the xUnit, OO-style, test frameworks there's a pattern called
>> Abstract Test Case, where all test methods reside in a base class,
>> together with one or more abstract methods denoting variance. Then you
>> create derived, concrete classes that implement the variations for the
>> specific types, and the runner sees them as separate suites.
>>
>> That's essentially what you're describing above, except you would have
>> to repeat every test case for every variation.
>>
>> I wonder if there's a way to use Boost.Test fixtures to implement
>> Abstract Test Case with a type variation...?
>>
>
> This seems to be the recommended usage pattern for testing generic
> components with different template patterns:
> http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/generic.html#id663542
>
Great find Glyn! Yup, this looks like the way to do it. :-)
Also, there's a way to have fixtures too (like setUp and tearDown) --
I don't know if we use this yet in the project, but I remember using
this for one of my proprietary projects back then. :)
Do either of you mind doing this on my URI implementation branch?
Maybe merging John's tests and mine into a single "coherent" test
suite? :D
BTW, does anybody want to take on a URL-encoding template function
that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
function implemented as a standalone function so that we can write
user code like this:
http::uri instance = string("http://foo.bar.com/q?") +
urlencode("yadda='The quick brown fox! Jumps over the lazy
dog?#)(*#)@");
HTH :)
--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Glyn M. <gly...@gm...> - 2009-11-09 13:20:49
|
Hi Dean,
2009/11/9 Dean Michael Berris <mik...@gm...>
>
>
<snip>
> Do either of you mind doing this on my URI implementation branch?
> Maybe merging John's tests and mine into a single "coherent" test
> suite? :D
> BTW, does anybody want to take on a URL-encoding template function
> that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
> function implemented as a standalone function so that we can write
> user code like this:
>
> http::uri instance = string("http://foo.bar.com/q?") +
> urlencode("yadda='The quick brown fox! Jumps over the lazy
> dog?#)(*#)@");
>
>
Please create Trac tickets for any ideas that you want others to pick up,
they'll just get lost on the mailing list.
G
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-09 15:47:38
|
On Mon, Nov 9, 2009 at 9:20 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/11/9 Dean Michael Berris <mik...@gm...>
>>
>
> <snip>
>>
>> Do either of you mind doing this on my URI implementation branch?
>> Maybe merging John's tests and mine into a single "coherent" test
>> suite? :D
>>
>> BTW, does anybody want to take on a URL-encoding template function
>> that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
>> function implemented as a standalone function so that we can write
>> user code like this:
>>
>> http::uri instance = string("http://foo.bar.com/q?") +
>> urlencode("yadda='The quick brown fox! Jumps over the lazy
>> dog?#)(*#)@");
>>
>
> Please create Trac tickets for any ideas that you want others to pick up,
> they'll just get lost on the mailing list.
>
Ah, yes. I keep forgetting we have a Trac installation. :)
I'll send the ticket number to the list after I do it. :D
--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Dean M. B. <mik...@gm...> - 2009-11-09 16:08:32
|
On Mon, Nov 9, 2009 at 11:47 PM, Dean Michael Berris <mik...@gm...> wrote: > > Ah, yes. I keep forgetting we have a Trac installation. :) > > I'll send the ticket number to the list after I do it. :D > https://sourceforge.net/apps/trac/cpp-netlib/ticket/10 HTH! -- 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