cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Dean M. B. <mik...@gm...>]

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 &pound() {
>         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 &pound() {
>         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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

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 &pound() {
        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 &pound() {
        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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[John P. F. <jf...@ov...>]

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
>
>   

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Allister L. S. <all...@gm...>]

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.
>
>

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

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

[cpp-netlib-devel] Updates on urllib-dean branch

[Dean M. B. <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.

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

Re: [cpp-netlib-devel] header vs compiled

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

2009/10/25 John P. Feltz <jf...@ov...>

> This borderline qualitative, but:
>
> 10.1 sec for uri_rfc1945_spirit_grammar.
> cpu: 2.1 ghz intel Core(TM)2 Duo CPU T7500  @ 2.20GHz
> ram: 2gb
> h/w: thinkpad t61
> soft: gcc version 4.3.4 (Debian 4.3.4-1)
>
> I have no $ for distributed builds so I can't judge that :). Running
> tests like this is just painful.
>

It doesn't take 10 seconds for me to compile that file (either using the
configuration I mentioned before, or on windows XP with MSVC 8), so it's
difficult to say what the issue is with that.

Glyn

Re: [cpp-netlib-devel] header vs compiled

[John P. F. <jf...@ov...>]

This borderline qualitative, but:

10.1 sec for uri_rfc1945_spirit_grammar.
cpu: 2.1 ghz intel Core(TM)2 Duo CPU T7500  @ 2.20GHz
ram: 2gb
h/w: thinkpad t61
soft: gcc version 4.3.4 (Debian 4.3.4-1)

I have no $ for distributed builds so I can't judge that :). Running 
tests like this is just painful.
As far as progress goes with uri, I think most of the technical hurtles 
are overcome (I'm assuming sub-classing from spirit's parser template 
maze is as hard as it gets). What is left in my branch seems pretty 
straight forward.

John

Glyn Matthews wrote:
> Hi John,
>
> 2009/10/25 John P. Feltz <jf...@ov...>
>
>   
>> I am starting to doubt the header only principle of the netlib.
>>     
>
>
> How long exactly does it take to compile exactly?  I just checked out your
> branch and built everything from scratch using a relatively recent g++ built
> from trunk (4.5.0) as well as g++ 4.2 and I didn't feel that either took
> excessively long.  Also, I have never experienced compile times to be a
> significant bottleneck in development.  Large projects are going to be built
> distributed anyway.
>
> Also, it will mean a major architectural change because we'd have to abandon
> the use of templates and traits to specialize the URI or client.
>
> What compiler are you using?  What about other factors that affect your
> build time?
>
> Apart from this, how is progress?
>
> Thanks,
> Glyn
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

Re: [cpp-netlib-devel] header vs compiled

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

Hi John,

2009/10/25 John P. Feltz <jf...@ov...>

> I am starting to doubt the header only principle of the netlib.


How long exactly does it take to compile exactly?  I just checked out your
branch and built everything from scratch using a relatively recent g++ built
from trunk (4.5.0) as well as g++ 4.2 and I didn't feel that either took
excessively long.  Also, I have never experienced compile times to be a
significant bottleneck in development.  Large projects are going to be built
distributed anyway.

Also, it will mean a major architectural change because we'd have to abandon
the use of templates and traits to specialize the URI or client.

What compiler are you using?  What about other factors that affect your
build time?

Apart from this, how is progress?

Thanks,
Glyn

[cpp-netlib-devel] header vs compiled

[John P. F. <jf...@ov...>]

I am starting to doubt the header only principle of the netlib. If this 
is open for debate, than I think we should look at the time incurred not 
only by the compile length of the library, but also of recently employed 
dependencies (a spirit based URI implementation). It could be reasoned, 
if the time required for the tests is any indication, that they will 
only get longer for the end-user as features are added. At what point 
does this become intolerable? This library has barely scratched the 
surface, and it seems to me that it would behoove both the user and the 
developer if these times could be cut down.

John

Re: [cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Dean M. B. <mik...@gm...>]

On Wed, Oct 14, 2009 at 3:30 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Oct 14, 2009 at 09:17, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> I'm trying to do that even through Visual Studio 2008 Express Edition
>> Command Line utility but Boost.Build seems to be looking for a Jamfile
>> and is not honoring the Jamroot file anymore. Maybe I should update my
>> Boost.Trunk checkout again.
>
> I don't entirely understand what you're saying, but one thing I've
> observed is that if you run bjam from the libs/network/test directory,
> the build fails, but if you run it from cpp-netlib's root, it
> succeeds. Does that help at all?
>

Will find out soon enough. Give me a couple of hours to get some work
stuff out of the way. ;)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Kim G. <kim...@gm...>]

Hi Dean,

On Wed, Oct 14, 2009 at 09:17, Dean Michael Berris
<mik...@gm...> wrote:
>
> I'm trying to do that even through Visual Studio 2008 Express Edition
> Command Line utility but Boost.Build seems to be looking for a Jamfile
> and is not honoring the Jamroot file anymore. Maybe I should update my
> Boost.Trunk checkout again.

I don't entirely understand what you're saying, but one thing I've
observed is that if you run bjam from the libs/network/test directory,
the build fails, but if you run it from cpp-netlib's root, it
succeeds. Does that help at all?

- Kim

Re: [cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Dean M. B. <mik...@gm...>]

Hi Kim,

On Wed, Oct 14, 2009 at 4:14 AM, Kim Gräsman <kim...@gm...> wrote:
> Huh. After making sure to build and use bjam.exe from Boost's trunk,
> and running "bjam -a" in cpp-netlib's root directory (trunk),
> everything just ran through successfully...
>

I'm trying to do that even through Visual Studio 2008 Express Edition
Command Line utility but Boost.Build seems to be looking for a Jamfile
and is not honoring the Jamroot file anymore. Maybe I should update my
Boost.Trunk checkout again.

I'll try sending an email with the exact error message later on in the
day. Hopefully I'll get this figured out soon -- unless we provide a
Visual C++ Project file for testing on Windows which is yucky for me
to say the least. ;)

> - Kim
>
> On Tue, Oct 13, 2009 at 22:10, Kim Gräsman <kim...@gm...> wrote:
>> Hi Dean,
>>
>> I've been struggling with that exact setup myself. I think I had it
>> sorted at one point, but now I can't get it to build again.
>>
>> The problem here is that the tests fail to link with Boost.Test, and
>> it doesn't seem to want to build it via the stated dependency.
>>
>> Currently it wants to link with
>> 'libboost_unit_test_framework-vc90-mt-gd-1_36.lib', and building
>> Boost.Test yields 'boost_unit_test_framework-vc90-gd-1_38.lib'
>>
>> There's something funny about Boost.Test, especially together with
>> Boost.Build, and I can't quite sort it out...
>>
>> - Kim
>>
>> On Tue, Oct 13, 2009 at 18:50, Dean Michael Berris
>> <mik...@gm...> wrote:
>>> Hi Guys,
>>>
>>> Am I the only one having trouble with building the cpp-netlib tests on
>>> Windows with Boost.Trunk?
>>>
>>> I was trying to set up a personal development machine here which used
>>> to be able to build the cpp-netlib codebase using the Jamfiles. I've
>>> updated to the latest, and Boost.Build seems to be looking for the
>>> Jamfile that used to be in the Boost root directory.
>>>
>>> I'm really close to giving up support on Windows, because mainly I
>>> can't get back to building the code in it.
>>>
>>> Thanks in advance and I hope you guys can help.
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) 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/devconference
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>



-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Kim G. <kim...@gm...>]

Huh. After making sure to build and use bjam.exe from Boost's trunk,
and running "bjam -a" in cpp-netlib's root directory (trunk),
everything just ran through successfully...

- Kim

On Tue, Oct 13, 2009 at 22:10, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> I've been struggling with that exact setup myself. I think I had it
> sorted at one point, but now I can't get it to build again.
>
> The problem here is that the tests fail to link with Boost.Test, and
> it doesn't seem to want to build it via the stated dependency.
>
> Currently it wants to link with
> 'libboost_unit_test_framework-vc90-mt-gd-1_36.lib', and building
> Boost.Test yields 'boost_unit_test_framework-vc90-gd-1_38.lib'
>
> There's something funny about Boost.Test, especially together with
> Boost.Build, and I can't quite sort it out...
>
> - Kim
>
> On Tue, Oct 13, 2009 at 18:50, Dean Michael Berris
> <mik...@gm...> wrote:
>> Hi Guys,
>>
>> Am I the only one having trouble with building the cpp-netlib tests on
>> Windows with Boost.Trunk?
>>
>> I was trying to set up a personal development machine here which used
>> to be able to build the cpp-netlib codebase using the Jamfiles. I've
>> updated to the latest, and Boost.Build seems to be looking for the
>> Jamfile that used to be in the Boost root directory.
>>
>> I'm really close to giving up support on Windows, because mainly I
>> can't get back to building the code in it.
>>
>> Thanks in advance and I hope you guys can help.
>

Re: [cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Kim G. <kim...@gm...>]

Hi Dean,

I've been struggling with that exact setup myself. I think I had it
sorted at one point, but now I can't get it to build again.

The problem here is that the tests fail to link with Boost.Test, and
it doesn't seem to want to build it via the stated dependency.

Currently it wants to link with
'libboost_unit_test_framework-vc90-mt-gd-1_36.lib', and building
Boost.Test yields 'boost_unit_test_framework-vc90-gd-1_38.lib'

There's something funny about Boost.Test, especially together with
Boost.Build, and I can't quite sort it out...

- Kim

On Tue, Oct 13, 2009 at 18:50, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Guys,
>
> Am I the only one having trouble with building the cpp-netlib tests on
> Windows with Boost.Trunk?
>
> I was trying to set up a personal development machine here which used
> to be able to build the cpp-netlib codebase using the Jamfiles. I've
> updated to the latest, and Boost.Build seems to be looking for the
> Jamfile that used to be in the Boost root directory.
>
> I'm really close to giving up support on Windows, because mainly I
> can't get back to building the code in it.
>
> Thanks in advance and I hope you guys can help.

[cpp-netlib-devel] Trouble with Boost.Trunk+Windows 2008 Express

[Dean M. B. <mik...@gm...>]

Hi Guys,

Am I the only one having trouble with building the cpp-netlib tests on
Windows with Boost.Trunk?

I was trying to set up a personal development machine here which used
to be able to build the cpp-netlib codebase using the Jamfiles. I've
updated to the latest, and Boost.Build seems to be looking for the
Jamfile that used to be in the Boost root directory.

I'm really close to giving up support on Windows, because mainly I
can't get back to building the code in it.

Thanks in advance and I hope you guys can help.

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

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

[Dean M. B. <mik...@gm...>]

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

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

[John P. F. <jf...@ov...>]

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

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

[John P. F. <jf...@ov...>]

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

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

[Dean M. B. <mik...@gm...>]

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