cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Urdl

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

Hi Matt,

2009/6/26 Matt Trentini <mat...@gm...>

> Hello folks,
>
> Christopher Kohlhoff, primary author and maintainer of the Boost Asio
> library, has recently announced Urdl:
>
>


> There are other pros/cons with the libraries.  Here are some differences:
>
>  o Urdl uses a stream-based approach whereas cpp-netlib uses a
> message and message parser abstraction.
>  o Cpp-netlib requires Boost 1.35 (I think. I'm using it with 1.37).
> Urdl requires 1.38.
>  o Urdl offers flexible deployment options (shared, static or
> header-only). Cpp-netlib is header-only.
>  o Urdl offers HTTPS (which requires OpenSSL)
>  o Urdl provides timeouts
>  o Cpp-netlib appears to be more stable.  Urdl is still very much
> under active development
>  o Urdl's documentation is more complete
>

> Was there any other points that are worth noting?  What else does
> cpp-netlib (or Urdl) do?
>

The first three aren't terribly important differences, the rest are fair and
I think its down to the inertia that this project is currently in.  HTTPS
and timeouts are things that normally we should be able to offer, as soon as
someone gets round to doing it.  The goal of cpp-netlib is to be highly
extensible through it's basic_message template, and I think ultimately we'd
like to support a much wider range of protocols than HTTP, HTTPS and FTP.
As for Urdl, I don't know what Chris Kohlhoff's intentions are for it so its
difficult to say any more on that.


> I guess what I'm raising is where should we focus our efforts?  Should
> we combine the projects, discard one, or continue as-is?  Personally I
> think a bad result would be to have two very similar decent C++
> libraries that have a huge overlap in features...  (An opinion which
> seems to be shared with others on this project given the efforts to
> integrate Pion.)
>

I would say continue as-is.  I'd like to devote more time to cpp-netlib, but
with work and moving I won't be able to just yet.


>
> I intend to contact Chris about what his intentions are with Urdl
> (intending on submitting it to Boost?  Leaving it as an Asio example?)
> but I thought I'd just see what you folks think first...
>

I think its worthing getting in touch with him for sure.  If he intends to
work on something that we're also interested in then none of us wants to see
this effort duplicated.  And since we're all big supporters of Boost.Asio
here we'd definitely be interested in what he has to say.

Glyn

[cpp-netlib-devel] Urdl

[Matt T. <mat...@gm...>]

Hello folks,

Christopher Kohlhoff, primary author and maintainer of the Boost Asio
library, has recently announced Urdl:

  http://www.nabble.com/-ann--Urdl---a-library-for-downloading-web-content-td24065122.html
  http://www.think-async.com/Urdl

There is a lot of overlap between what Urdl and cpp-netlib provide.
They both parse URL's and can make HTTP calls.

I've been looking at adding timeouts to cpp-netlib and found that this
is a feature that Urdl already has...

There are other pros/cons with the libraries.  Here are some differences:

  o Urdl uses a stream-based approach whereas cpp-netlib uses a
message and message parser abstraction.
  o Cpp-netlib requires Boost 1.35 (I think. I'm using it with 1.37).
Urdl requires 1.38.
  o Urdl offers flexible deployment options (shared, static or
header-only). Cpp-netlib is header-only.
  o Urdl offers HTTPS (which requires OpenSSL)
  o Urdl provides timeouts
  o Cpp-netlib appears to be more stable.  Urdl is still very much
under active development
  o Urdl's documentation is more complete

Was there any other points that are worth noting?  What else does
cpp-netlib (or Urdl) do?

I guess what I'm raising is where should we focus our efforts?  Should
we combine the projects, discard one, or continue as-is?  Personally I
think a bad result would be to have two very similar decent C++
libraries that have a huge overlap in features...  (An opinion which
seems to be shared with others on this project given the efforts to
integrate Pion.)

I intend to contact Chris about what his intentions are with Urdl
(intending on submitting it to Boost?  Leaving it as an Asio example?)
but I thought I'd just see what you folks think first...

Cheers,
Matt

Re: [cpp-netlib-devel] HTTP Timeouts

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

On Tue, Jun 16, 2009 at 2:38 PM, Glyn Matthews<gly...@gm...> wrote:
>
> 2009/6/16 Matt Trentini <mat...@gm...>
>>
>> So.....has anyone done this before?  Shall I roll up my sleeves and
>> start coding a solution into cpp-netlib or has someone already begun?
>
> I don't think anyone is working on this.  If you want to start then please
> do :)
>

+1 :)

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

Re: [cpp-netlib-devel] HTTP Timeouts

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

Hi Matt,

2009/6/16 Matt Trentini <mat...@gm...>

> Hello folks,
>
> What's the recommended way to handle HTTP timeouts with cpp-netlib?
>
> We could use a deadline_timer but, externally, we don't have access to
> the io_service (so we'd need to push the timeout handline into the
> library).  In fact this solution is discussed in a boost forum thread
> started by our own Dean:
>
>  http://lists.boost.org/Archives/boost/2007/04/120290.php
>
> Looks remarkably similar to what we require!  :)
>

I think that's the right solution, and I believe that's what Dean refers to
in his post here:

http://tinyurl.com/n32dqf*

*

>
> So.....has anyone done this before?  Shall I roll up my sleeves and
> start coding a solution into cpp-netlib or has someone already begun?
>

I don't think anyone is working on this.  If you want to start then please
do :)

Regards,
Glyn

[cpp-netlib-devel] HTTP Timeouts

[Matt T. <mat...@gm...>]

Hello folks,

What's the recommended way to handle HTTP timeouts with cpp-netlib?
Specifically I want to be able to set a timeout (to say, 300ms) and
then have the library indicate (probably throw an exception) when the
request takes longer than the timeout.

I can see that there's a connection_timeout
(network/protocol/http/errors.hpp) exception defined but it appears to
be unused.

Now I could start a thread, timed_join it etc but that's pretty
heavyweight and ugly.

We could use a deadline_timer but, externally, we don't have access to
the io_service (so we'd need to push the timeout handline into the
library).  In fact this solution is discussed in a boost forum thread
started by our own Dean:

  http://lists.boost.org/Archives/boost/2007/04/120290.php

Looks remarkably similar to what we require!  :)

So.....has anyone done this before?  Shall I roll up my sleeves and
start coding a solution into cpp-netlib or has someone already begun?

Thanks,
Matt

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

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

Hi Matt,

2009/5/26 Matt Trentini <mat...@gm...>

> Heya folks,
>
> I'm just wondering about the status of cpp-netlib?  Dean, Glyn, are
> you guys still working on the project?
>

I'd say the status is that it's alive, just not very active.  I also have
the same problem with committing time and energy to this project as Mike and
Dean.

I'd be interested in hearing more about what you're using cpp-netlib for and
about any ideas you can contribute.
Thanks for your interest.
Glyn


> Our group is looking to make REST calls and, as we're already heavily
> using boost, cpp-netlib seemed the strongest candidate.
>
> Pion also looked like a great candidate but I saw that Mike announced
> (http://www.pion.org/node/77) that his intention was to merge Pion to
> cpp-netlib and, ultimately, to put together a library that could be
> submitted to boost.  Sounds great to me!  However that was over a year
> ago and although some integration seems to have occurred there doesn't
> seem to have been any work for some time.  I also notice that Pion has
> had a number of releases since.  Is the intention still to merge more
> of Pion to cpp-netlib?
>
> Assuming the project is still active I'll do what I can to help out.
>
> Cheers,
> Matt
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

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

On Tue, May 26, 2009 at 11:56 AM, Matt Trentini <mat...@gm...> wrote:
>
>> I'm currently really busy with the day job taking on a more important
>> role in the team.
>
> I sympathise with your "pain"!  ;)
>

Thanks. :-D

>> I personally am already using cpp-netlib in a couple of production
>> projects already and I can say it's proven to be stable enough for
>> REST use cases. I have successfully used cpp-netlib to interface with
>> Amazon AWS in a previous project and I think that's good enough
>> quality to build software around (if I may say so myself). ;-)
>
> I've been putting together a few small applications using cpp-netlib
> but I'm about to integrate it into our main codebase and so will be
> relying on it heavily over the next couple of weeks/months.
>

Sweet! :-)

> I've got a couple of specific issues/queries but I'll leave them for
> another email.
>
> After spending a bit of time looking over the codebase I'd agree that
> the quality of the code is pretty high.  It's initially quite dense
> (mostly due to the fusion compile-time templates and tags) and
> documentation is a little sparse (are you considering publishing the
> doco?) but once you get a feel for it the design seems sound and the
> code solid.
>

The internal documentation isn't really a priority for me (personally)
basically because I believe the code should be readable enough on its
own -- so that I (or others) don't have to maintain the internal
documentation and the external documentation. Sure, you can generate
doxygen documentation, but that would only get so far IMO.

What I spent some time on is working on the actual gears that make the
internals work and describing the whole picture in the architecture
documentation. Some of the examples are meant to be guides, and if I
attempt to write about the idioms used in the code, it's going to be a
book like what Andrei Alexandrescu and other great authors have
already written before me. :-D

>> The server-side HTTP implementation however is something that I'm
>> currently fighting for to be released by my employer as Open Source
>> software. We've been using this HTTP server internally in production
>> and has proven to be flexible, extensible, and high performance enough
>> that I think it's worth the wait.
>
> Good luck with that, I'm sure the C++ community would appreciate it.
> FWIW we're currently using a modified version of one the boost::asio
> examples to handle incoming http requests.
>

Thanks. :-)

>> I am personally waiting for the next standard before implementing much of the things I'm envisioning for the library.
>
> I'm looking forward to the next standard too but I wouldn't have
> thought it would hold you up too much?
>

Right, that and the day job is giving me much to be busy on. ;-)

>> More specifically, I'm waiting for:
>>
>> - standardized futures
>
> Absolutely.  Anthony Williams has been doing some great work in this
> space (http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html).
>  Looking forward to seeing his future library in boost soon (as I
> recall it's been accepted but not integrated yet).
>

Yup. And I'm looking forward to an STL that implements its own
threadpool -- that way I can use them in the asynchronous client
version I'm thinking about implementing.

>> - rvalue references and move semantics (for better performance)
>> - variadic templates
>> - auto and decltype
>
> All useful, for sure.  I'm also keen to see lambdas.
>

Lambdas are cool on their own. :-) But for building cpp-netlib I don't
see it as being an integral part of what I am envisioning the code
would look like. Maybe for supporting asynchronous handlers, users of
the library can rely on lambdas, but internally I don't see the need
for it just yet.

>> Much of the code would work without these features but if writing more
>> and more features would be an effort that later would have to be
>> re-written I'm thinking of deferring the bulk of the work for later.
>
> Well, boost certainly appreciates compatibility with older compilers
> so if you are going for acceptance...  :)
>

You're right. :D I should clear some of the modifications I've done
for the employer so that it can be checked into the source tree.
Hopefully they'll be keen on getting more open source code out sooner
than later. ;-)

>> In the meantime though, you can get the latest released version and
>> try using it in your project -- we would love to hear what your
>> experience is like. In case you need anything specific addressed, I'm
>> sure we can work together to make it happen.
>
> Will do!  I've been hesitant to post because I haven't really
> understood the library well enough but I think I've got enough
> experience now that I (hopefully) won't be wasting everyone's time.
>

That definitely sounds encouraging to me. :-)

> Thanks for such a prompt response.
>

No worries, don't forget to let us know about your progress and
experiences with the library! :-)

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

Re: [cpp-netlib-devel] Query parameters

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

Hi Matt!

On Tue, May 26, 2009 at 12:27 PM, Matt Trentini <mat...@gm...> wrote:
> Hello folks,
>
> How are query parameters meant to be set with cpp-netlib?
>

There used to be a project which should have moved the URI
building/manipulation out of the http::request class implementation
into its own. At the moment, it's all ad-hoc and undefined really.

>
>    http::request
> request("http://hudson_server/hudson/api/xml?xpath=//job[name='mainjob']/color/text()");
>    http::client client;
>    http::response response;
>    response = client.get(request);
>    cout << body(response) << endl;
>
> The "/"'s in the xpath query cause problems.  The parser in
> request.hpp (specifically, line 94) fails to match the "/" and
> discards the query parameters.
>
> [As an aside I appreciate that "/" is a reserved character in an URI
> but haven't dug far enough into the RFC
> (http://www.ietf.org/rfc/rfc3986.txt) to determine whether this usage
> of it makes for a valid URI.  I *think* it is valid - even without
> escaping - based on section 3.4 but I'm not 100%.]
>

Thanks for the link, I looked it up and this is what I found about the
Query string:

3.4.  Query

   The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).  The query component is indicated by the first question
   mark ("?") character and terminated by a number sign ("#") character
   or by the end of the URI.

      query       = *( pchar / "/" / "?" )

   The characters slash ("/") and question mark ("?") may represent data
   within the query component.  Beware that some older, erroneous
   implementations may not handle such data correctly when it is used as
   the base URI for relative references (Section 5.1), apparently
   because they fail to distinguish query data from path data when
   looking for hierarchical separators.  However, as query components
   are often used to carry identifying information in the form of
   "key=value" pairs and one frequently used value is a reference to
   another URI, it is sometimes better for usability to avoid percent-
   encoding those characters.

So it looks like the parsing should treat whatever is after the first
'?' character upto the character before the '#' character.

> I've worked around the issue with the following change:
>

[snip]

>    -                    >> (+(alnum_p | '&' | '=' | '%' | '_' ))[
>    +                    >> (+(anychar_p | '&' | '=' | '%' | '_' ))[

[snip]

After reading the RFC, I'd think the parser above should accept
anything except the '#' character. I'm a little rusty with my Spirit
powers, but I'd think it can be achieved easily.

[snip]
>
> But that's quite dirty!
>

I agree. :-)

> I'm wondering if there's a better way to set queries for a request?  I
> couldn't find anything in the code but I may well have missed
> something.
>
> I suppose I was looking for something like:
>
>    http::request request("http://hudson_server/hudson/api/xml");
>    request.addQuery("xpath", "//job[name='mainjob']/color/text()")
>
> That way the parser could add the surrounding stuff (question marks,
> amperstands etc) for me.  As it turns out this is similar to how
> Pion's HTTPRequest class handles queries.
>

I am a fan of DSEL's (if you haven't noticed yet ;-) ), and it would
be feasible (with Boost.Proto maybe or the same way I came up with the
request builder protocol) to enable something like:

  http::request request("http://hudson_server/hudson/api/xml");
  build(request) << query_param("xpath", "//job[name='mainjob']/color/text()")
    << query_param("something_else","Some data that gets automatically
encoded!")
    << fragment("home");

I'm positive the encoding and parsing can benefit from an upgrade to
using Spirit 2.0 (Qi and Karma).

> BTW I did notice there is a query() method to *return* the query
> string.  I also noticed the "make_query_string" method but I wasn't
> sure if I could (or should) try and use it since it was in an impl
> file.  It also doesn't seem to be used internally either though...
>

I remember that query() method in the request object -- although I
forget what the 'make_query_string' method was supposed to do.

> Any comments?  Am I doing something obviously wrong?

Aside from what I've said above, I think you found a legitimate bug. :-)

Thanks for raising the concern! :-D

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

[cpp-netlib-devel] Query parameters

[Matt T. <mat...@gm...>]

Hello folks,

How are query parameters meant to be set with cpp-netlib?

As a test I was trying to perform a GET to our Hudson
(https://hudson.dev.java.net/) build server.  The request looks
something like this:

    http::request
request("http://hudson_server/hudson/api/xml?xpath=//job[name='mainjob']/color/text()");
    http::client client;
    http::response response;
    response = client.get(request);
    cout << body(response) << endl;

The "/"'s in the xpath query cause problems.  The parser in
request.hpp (specifically, line 94) fails to match the "/" and
discards the query parameters.

[As an aside I appreciate that "/" is a reserved character in an URI
but haven't dug far enough into the RFC
(http://www.ietf.org/rfc/rfc3986.txt) to determine whether this usage
of it makes for a valid URI.  I *think* it is valid - even without
escaping - based on section 3.4 but I'm not 100%.]

I've worked around the issue with the following change:

    Index: boost/network/protocol/http/impl/request.hpp
    ===================================================================
    --- boost/network/protocol/http/impl/request.hpp	(revision 142)
    +++ boost/network/protocol/http/impl/request.hpp	(working copy)
    @@ -91,7 +91,7 @@
                             = construct_<typename
string_traits<tag>::type>(arg1, arg2)
                     ]
                     >> !(ch_p('?')
    -                    >> (+(alnum_p | '&' | '=' | '%' | '_' ))[
    +                    >> (+(anychar_p | '&' | '=' | '%' | '_' ))[
                             var(fusion::at_key<typename
tags::query>(uri_parts))
                                 = construct_<typename
string_traits<tag>::type>(arg1, arg2)
                         ]

But that's quite dirty!

I'm wondering if there's a better way to set queries for a request?  I
couldn't find anything in the code but I may well have missed
something.

I suppose I was looking for something like:

    http::request request("http://hudson_server/hudson/api/xml");
    request.addQuery("xpath", "//job[name='mainjob']/color/text()")

That way the parser could add the surrounding stuff (question marks,
amperstands etc) for me.  As it turns out this is similar to how
Pion's HTTPRequest class handles queries.

BTW I did notice there is a query() method to *return* the query
string.  I also noticed the "make_query_string" method but I wasn't
sure if I could (or should) try and use it since it was in an impl
file.  It also doesn't seem to be used internally either though...

Any comments?  Am I doing something obviously wrong?

Cheers,
Matt

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

[Matt T. <mat...@gm...>]

Heya Mike,

> Speaking only for myself here..   Merging it in was the intention but
> I was probably way too optimistic on my time availability to help make
> that happen.

You wouldn't be a software engineer if you weren't optimistic.  ;)

But it does seem like some of Pion got in - parser.ipp looks mostly
like Pion code?

> Reality set in and it just never really developed enough
> momentum..  There was an attempt to try to get some GSoC help
> (including some great applicants who were interested in working on it)
> but that was unfortunately unsuccessful.

I saw that; disappointing.

> I'm still in support of the idea, but as I understand it, cpp-netlib
> has come a long way on its own and is now a very usable client-side
> library.

Yes, it definitely seems to be.

> Although pion-net has some client side capabilities, its
> strength is really in building a fast & extensible Boost-based HTTP
> server and that is really what it was designed for (its client side
> API is a bit kludgy right now because of that, IMHO).  Although we
> continue to release updates to pion-net and use it extensively within
> our products, I don't believe Atomic Labs has made any really big
> changes to the library over the past year.

Makes sense, thanks for the update.

> So, if you're looking to build a fast HTTP server interface into your
> application, pion-net is probably the better choice.  But if you're
> looking for a client-side library and cpp-netlib does what you need,
> then it is probably the way to go.

That makes things clearer.  Currently we're ok with our
asio-butchered-example server but I'll keep Pion in mind if we're
thinking of upgrading.

> P.S.  I'm happy to support and work with anyone who can help make the
> merge happen.  If we can end up merging the two (without loss of
> functionality), I'll be happy to switch over to using the new library
> in the rest of our (Atomic Labs') code.  Unfortunately, I just don't
> have a lot of time available these days to lead the effort myself.

Being in a similar position myself I completely understand.

Thanks for your efforts and your reply!

Cheers,
Matt

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

[Matt T. <mat...@gm...>]

Heya Dean,

> I'm currently really busy with the day job taking on a more important
> role in the team.

I sympathise with your "pain"!  ;)

> I personally am already using cpp-netlib in a couple of production
> projects already and I can say it's proven to be stable enough for
> REST use cases. I have successfully used cpp-netlib to interface with
> Amazon AWS in a previous project and I think that's good enough
> quality to build software around (if I may say so myself). ;-)

I've been putting together a few small applications using cpp-netlib
but I'm about to integrate it into our main codebase and so will be
relying on it heavily over the next couple of weeks/months.

I've got a couple of specific issues/queries but I'll leave them for
another email.

After spending a bit of time looking over the codebase I'd agree that
the quality of the code is pretty high.  It's initially quite dense
(mostly due to the fusion compile-time templates and tags) and
documentation is a little sparse (are you considering publishing the
doco?) but once you get a feel for it the design seems sound and the
code solid.

> The server-side HTTP implementation however is something that I'm
> currently fighting for to be released by my employer as Open Source
> software. We've been using this HTTP server internally in production
> and has proven to be flexible, extensible, and high performance enough
> that I think it's worth the wait.

Good luck with that, I'm sure the C++ community would appreciate it.
FWIW we're currently using a modified version of one the boost::asio
examples to handle incoming http requests.

> I am personally waiting for the next standard before implementing much of the things I'm envisioning for the library.

I'm looking forward to the next standard too but I wouldn't have
thought it would hold you up too much?

> More specifically, I'm waiting for:
>
> - standardized futures

Absolutely.  Anthony Williams has been doing some great work in this
space (http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html).
 Looking forward to seeing his future library in boost soon (as I
recall it's been accepted but not integrated yet).

> - rvalue references and move semantics (for better performance)
> - variadic templates
> - auto and decltype

All useful, for sure.  I'm also keen to see lambdas.

> Much of the code would work without these features but if writing more
> and more features would be an effort that later would have to be
> re-written I'm thinking of deferring the bulk of the work for later.

Well, boost certainly appreciates compatibility with older compilers
so if you are going for acceptance...  :)

> In the meantime though, you can get the latest released version and
> try using it in your project -- we would love to hear what your
> experience is like. In case you need anything specific addressed, I'm
> sure we can work together to make it happen.

Will do!  I've been hesitant to post because I haven't really
understood the library well enough but I think I've got enough
experience now that I (hopefully) won't be wasting everyone's time.

Thanks for such a prompt response.

Cheers,
Matt

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

[Michael D. <mi...@at...>]

Hi Matt,

Speaking only for myself here..   Merging it in was the intention but  
I was probably way too optimistic on my time availability to help make  
that happen.  Reality set in and it just never really developed enough  
momentum..  There was an attempt to try to get some GSoC help  
(including some great applicants who were interested in working on it)  
but that was unfortunately unsuccessful.

I'm still in support of the idea, but as I understand it, cpp-netlib  
has come a long way on its own and is now a very usable client-side  
library.  Although pion-net has some client side capabilities, its  
strength is really in building a fast & extensible Boost-based HTTP  
server and that is really what it was designed for (its client side  
API is a bit kludgy right now because of that, IMHO).  Although we  
continue to release updates to pion-net and use it extensively within  
our products, I don't believe Atomic Labs has made any really big  
changes to the library over the past year.

So, if you're looking to build a fast HTTP server interface into your  
application, pion-net is probably the better choice.  But if you're  
looking for a client-side library and cpp-netlib does what you need,  
then it is probably the way to go.

Take care,
-Mike

P.S.  I'm happy to support and work with anyone who can help make the  
merge happen.  If we can end up merging the two (without loss of  
functionality), I'll be happy to switch over to using the new library  
in the rest of our (Atomic Labs') code.  Unfortunately, I just don't  
have a lot of time available these days to lead the effort myself.


On May 25, 2009, at 6:59 PM, Matt Trentini wrote:

> Heya folks,
>
> I'm just wondering about the status of cpp-netlib?  Dean, Glyn, are
> you guys still working on the project?
>
> Our group is looking to make REST calls and, as we're already heavily
> using boost, cpp-netlib seemed the strongest candidate.
>
> Pion also looked like a great candidate but I saw that Mike announced
> (http://www.pion.org/node/77) that his intention was to merge Pion to
> cpp-netlib and, ultimately, to put together a library that could be
> submitted to boost.  Sounds great to me!  However that was over a year
> ago and although some integration seems to have occurred there doesn't
> seem to have been any work for some time.  I also notice that Pion has
> had a number of releases since.  Is the intention still to merge more
> of Pion to cpp-netlib?
>
> Assuming the project is still active I'll do what I can to help out.
>
> Cheers,
> Matt
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity  
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like  
> Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] cpp-netlib status (including Pion integration)

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

Hi Matt!

On Tue, May 26, 2009 at 9:59 AM, Matt Trentini <mat...@gm...> wrote:
> Heya folks,
>
> I'm just wondering about the status of cpp-netlib?  Dean, Glyn, are
> you guys still working on the project?
>

I'm currently really busy with the day job taking on a more important
role in the team.

At this time I'm waiting for the solidification of the next C++
standard (C++0x) before doing any major work on the software.

> Our group is looking to make REST calls and, as we're already heavily
> using boost, cpp-netlib seemed the strongest candidate.
>

I personally am already using cpp-netlib in a couple of production
projects already and I can say it's proven to be stable enough for
REST use cases. I have successfully used cpp-netlib to interface with
Amazon AWS in a previous project and I think that's good enough
quality to build software around (if I may say so myself). ;-)

> Pion also looked like a great candidate but I saw that Mike announced
> (http://www.pion.org/node/77) that his intention was to merge Pion to
> cpp-netlib and, ultimately, to put together a library that could be
> submitted to boost.  Sounds great to me!  However that was over a year
> ago and although some integration seems to have occurred there doesn't
> seem to have been any work for some time.  I also notice that Pion has
> had a number of releases since.  Is the intention still to merge more
> of Pion to cpp-netlib?
>

I think the client side of Pion is what's slated to be merged into the
cpp-netlib.

The server-side HTTP implementation however is something that I'm
currently fighting for to be released by my employer as Open Source
software. We've been using this HTTP server internally in production
and has proven to be flexible, extensible, and high performance enough
that I think it's worth the wait.

> Assuming the project is still active I'll do what I can to help out.

That sounds great.

I'd say it still is alive in my heart, although I cannot do much of
the heavy lifting at the moment given my (changing) role in the day
job. But FWIW, I am personally waiting for the next standard before
implementing much of the things I'm envisioning for the library. More
specifically, I'm waiting for:

- standardized futures
- rvalue references and move semantics (for better performance)
- variadic templates
- auto and decltype

Much of the code would work without these features but if writing more
and more features would be an effort that later would have to be
re-written I'm thinking of deferring the bulk of the work for later.

In the meantime though, you can get the latest released version and
try using it in your project -- we would love to hear what your
experience is like. In case you need anything specific addressed, I'm
sure we can work together to make it happen.

Thanks for dropping a line!

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

[cpp-netlib-devel] cpp-netlib status (including Pion integration)

[Matt T. <mat...@gm...>]

Heya folks,

I'm just wondering about the status of cpp-netlib?  Dean, Glyn, are
you guys still working on the project?

Our group is looking to make REST calls and, as we're already heavily
using boost, cpp-netlib seemed the strongest candidate.

Pion also looked like a great candidate but I saw that Mike announced
(http://www.pion.org/node/77) that his intention was to merge Pion to
cpp-netlib and, ultimately, to put together a library that could be
submitted to boost.  Sounds great to me!  However that was over a year
ago and although some integration seems to have occurred there doesn't
seem to have been any work for some time.  I also notice that Pion has
had a number of releases since.  Is the intention still to merge more
of Pion to cpp-netlib?

Assuming the project is still active I'll do what I can to help out.

Cheers,
Matt

Re: [cpp-netlib-devel] Get Git or Stay with SVN?

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

On Wed, Mar 4, 2009 at 7:25 PM, Glyn Matthews <gly...@gm...> wrote:
> Dean,
>
> 2009/3/4 Dean Michael Berris <mik...@gm...>
>>
>> On Wed, Mar 4, 2009 at 6:24 PM, Glyn Matthews <gly...@gm...>
>> wrote:
>> > I'm interested but I don't know a lot about Git.  Could you give a list
>> > of
>> > advantages?
>> >
>>
>> One of the advantages is local commits -- or offline commits -- which
>> allows for disconnected development.
>>
>> Another is the distributed aspect which allows everyone to have a copy
>> of the *repository* not just the local copy of the source. So you can
>> switch between branches, merge changes easily between and across
>> branches, etc.
>>
>> Yet another is an easy means for developing a release tar-ball with
>> the correct changelog from commit messages. :-)
>
> Sounds good, but I don't think its enough on its own to change the
> repository.
>

Yeah, now that I think about it more, I agree. :-)

>>
>> I'm personally using git-svn now with another project, and I'm trying
>> out git-svn to develop cpp-netlib further -- I'm thinking of merging
>> John's work into the http_integration branch -- and seeing whether I
>> can continue his work to support persistent connections and what not.
>
> Oooh it sounds like progress.  Also, don't forget there is some useful URI
> code gathering dust that should be merged into trunk.
>

Oh yes. I'm also thinking of picking it up and adding more tests to it
before I merge to http_integration and then into trunk. I want the
request object constructor to take a uri object that's constructed
(implicitly) from a string or char const *. Hopefully it won't be as
hard as I think it would be. ;-)

>>
>> So if we can stay with svn at Subversion, I don't mind but I
>> personally like developing on a Git repository from my VM. ;-)
>
>
> Even if we don't use it for this project, it might make an useful blog post
> ;)
>

Yeah. :-) I might write it one day when I get more into the groove of
doing it better. ;-)

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

Re: [cpp-netlib-devel] Get Git or Stay with SVN?

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

Dean,

2009/3/4 Dean Michael Berris <mik...@gm...>

> On Wed, Mar 4, 2009 at 6:24 PM, Glyn Matthews <gly...@gm...>
> wrote:
> > I'm interested but I don't know a lot about Git.  Could you give a list
> of
> > advantages?
> >
>
> One of the advantages is local commits -- or offline commits -- which
> allows for disconnected development.
>
> Another is the distributed aspect which allows everyone to have a copy
> of the *repository* not just the local copy of the source. So you can
> switch between branches, merge changes easily between and across
> branches, etc.
>
> Yet another is an easy means for developing a release tar-ball with
> the correct changelog from commit messages. :-)
>

Sounds good, but I don't think its enough on its own to change the
repository.


> I'm personally using git-svn now with another project, and I'm trying
> out git-svn to develop cpp-netlib further -- I'm thinking of merging
> John's work into the http_integration branch -- and seeing whether I
> can continue his work to support persistent connections and what not.
>

Oooh it sounds like progress.  Also, don't forget there is some useful URI
code gathering dust that should be merged into trunk.


>
> So if we can stay with svn at Subversion, I don't mind but I
> personally like developing on a Git repository from my VM. ;-)
>


Even if we don't use it for this project, it might make an useful blog post
;)

G

Re: [cpp-netlib-devel] Get Git or Stay with SVN?

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

On Wed, Mar 4, 2009 at 6:24 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/3/4 Dean Michael Berris <mik...@gm...>
>>
>> Hi Guys,
>>
>> I just wanted to throw it out there -- I'm considering using Git
>> instead of SVN with developing cpp-netlib. Are there any objections to
>> this?
>
> I'm interested but I don't know a lot about Git.  Could you give a list of
> advantages?
>

One of the advantages is local commits -- or offline commits -- which
allows for disconnected development.

Another is the distributed aspect which allows everyone to have a copy
of the *repository* not just the local copy of the source. So you can
switch between branches, merge changes easily between and across
branches, etc.

Yet another is an easy means for developing a release tar-ball with
the correct changelog from commit messages. :-)

>>
>> Recently Sourceforge just supported Git as one of the repository
>> options for projects. Do you think this would work better for us, or
>> would we be alienating Windows developers/users?
>
> Is there no port for Git on Windows?  If it makes development on Windows
> more difficult then it would be a big disadvantage because cpp-netlib should
> be cross platform.
>

I hear there are a few projects out there which allows for using Git
on Windows -- but none of them I tried.

I'm personally using git-svn now with another project, and I'm trying
out git-svn to develop cpp-netlib further -- I'm thinking of merging
John's work into the http_integration branch -- and seeing whether I
can continue his work to support persistent connections and what not.

So if we can stay with svn at Subversion, I don't mind but I
personally like developing on a Git repository from my VM. ;-)

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

Re: [cpp-netlib-devel] Get Git or Stay with SVN?

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

Hi Dean,

2009/3/4 Dean Michael Berris <mik...@gm...>

> Hi Guys,
>
> I just wanted to throw it out there -- I'm considering using Git
> instead of SVN with developing cpp-netlib. Are there any objections to
> this?
>

I'm interested but I don't know a lot about Git.  Could you give a list of
advantages?


>
> Recently Sourceforge just supported Git as one of the repository
> options for projects. Do you think this would work better for us, or
> would we be alienating Windows developers/users?
>

Is there no port for Git on Windows?  If it makes development on Windows
more difficult then it would be a big disadvantage because cpp-netlib should
be cross platform.

Glyn

[cpp-netlib-devel] Get Git or Stay with SVN?

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

Hi Guys,

I just wanted to throw it out there -- I'm considering using Git
instead of SVN with developing cpp-netlib. Are there any objections to
this?

Recently Sourceforge just supported Git as one of the repository
options for projects. Do you think this would work better for us, or
would we be alienating Windows developers/users?

Hope to hear from you guys soon!

-- 
Dean Michael Berris | Software Engineer, Friendster, Inc.
blog.cplusplus-soup.com | twitter.com/mikhailberis |
linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis |
deanberris.com

Re: [cpp-netlib-devel] Compile cpp-netlib

[Ankit <ad...@ma...>]

Thanks Micheal and Divye.

I was able to compile http_client. I'll look at the samples in test
directory also.

Thanks,
Ankit

On Thu, Feb 5, 2009 at 1:57 AM, Divye Kapoor <div...@gm...> wrote:

    Hello Ankit,

    Please have a look at some of the tests present in the distribution to
give you an idea of how to use the library interface.

    Welcome to CppNetlib!

    Regards,
    Divye Kapoor


    On Thu, Feb 5, 2009 at 4:19 AM, Dean Michael C. Berris
<dmb...@fr...> wrote:

        Hi Ankit,

        > -----Original Message-----
        > From: Ankit [mailto:ad...@ma...]
        > Sent: Thursday, February 05, 2009 6:28 AM
        > To: cpp...@li...
        > Subject: [cpp-netlib-devel] Compile cpp-netlib
        >
        > Hi,
        >
        > I am new to cpp-netlib and wanted to try out the library.
        >
        > Can anyone please suggest me how to compile it ?
        >
        > I want to compile it with boost-1.36.
        >

        The good thing with cpp-netlib is that you don't need to compile
        anything to use the library -- it's header-only and should work with
        Boost 1.36. :)

        HTH

        --
        Dean Michael Berris
        Software Engineer, Friendster, Inc.

        ------------------------------------------------------------------------------
        Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
        software. With Adobe AIR, Ajax developers can use existing skills
and code to
        build responsive, highly engaging applications that combine the
power of local
        resources and data with the reach of the web. Download the Adobe
AIR SDK and
        Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
        _______________________________________________
        Cpp-netlib-devel mailing list
        Cpp...@li...
        https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel




    --
    An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
       H. L. Mencken (1880 - 1956)
    My official web site: http://people.iitr.ernet.in/shp/061305/
    Webmaster: http://www.drkapoorsclinic.com
    Blog: http://divyekapoor.blogspot.com

    ------------------------------------------------------------------------------
    Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
    software. With Adobe AIR, Ajax developers can use existing skills and
code to
    build responsive, highly engaging applications that combine the power
of local
    resources and data with the reach of the web. Download the Adobe AIR
SDK and
    Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
    _______________________________________________
    Cpp-netlib-devel mailing list
    Cpp...@li...
    https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel

Re: [cpp-netlib-devel] Compile cpp-netlib

[Divye K. <div...@gm...>]

Hello Ankit,
Please have a look at some of the tests present in the distribution to give
you an idea of how to use the library interface.

Welcome to CppNetlib!

Regards,
Divye Kapoor

On Thu, Feb 5, 2009 at 4:19 AM, Dean Michael C. Berris <
dmb...@fr...> wrote:

> Hi Ankit,
>
> > -----Original Message-----
> > From: Ankit [mailto:ad...@ma...]
> > Sent: Thursday, February 05, 2009 6:28 AM
> > To: cpp...@li...
> > Subject: [cpp-netlib-devel] Compile cpp-netlib
> >
> > Hi,
> >
> > I am new to cpp-netlib and wanted to try out the library.
> >
> > Can anyone please suggest me how to compile it ?
> >
> > I want to compile it with boost-1.36.
> >
>
> The good thing with cpp-netlib is that you don't need to compile
> anything to use the library -- it's header-only and should work with
> Boost 1.36. :)
>
> HTH
>
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK
> and
> Ajax docs to start building applications today-
> http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>



-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
   H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] Compile cpp-netlib

[Dean M. C. B. <dmb...@fr...>]

Hi Ankit,

> -----Original Message-----
> From: Ankit [mailto:ad...@ma...] 
> Sent: Thursday, February 05, 2009 6:28 AM
> To: cpp...@li...
> Subject: [cpp-netlib-devel] Compile cpp-netlib
> 
> Hi,
> 
> I am new to cpp-netlib and wanted to try out the library.
> 
> Can anyone please suggest me how to compile it ?
> 
> I want to compile it with boost-1.36.
> 

The good thing with cpp-netlib is that you don't need to compile
anything to use the library -- it's header-only and should work with
Boost 1.36. :)

HTH

--
Dean Michael Berris
Software Engineer, Friendster, Inc. 

[cpp-netlib-devel] Compile cpp-netlib

[Ankit <ad...@ma...>]

Hi,

I am new to cpp-netlib and wanted to try out the library.

Can anyone please suggest me how to compile it ?

I want to compile it with boost-1.36.

Thanks,
Ankit

Re: [cpp-netlib-devel] soliciting ideas concerning client errors

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

Dean Michael Berris wrote:
> </snip>
>
> At any rate, since the basic_client is meant to be the "world-facing"
> API, it's not entirely impossible to write auxiliary classes that were
> used by a specialization of the basic_client with a different tag.
> What I mean by this is that for example, you can have a different tag
> and a different set of (new) traits and accessors from which you can
> design the basic_client specialization around.
>
> struct non_throwing_tag;
> struct persistent_connections_tag;
>
> namespace triats {
>   template <class T>
>   struct http_tag;
>
>   template <>
>   struct http_tag<non_throwing_tag> {
>     typedef http::message_tag type;
>   };
>
>   template <>
>   struct http_tag<persistent_connections_tag> {
>     typedef http::message_tag type;
>   };
> }
>
> template<>
> class basic_client<non_throwing_tag, 1, 0> {
>   // different API of a client that doesn't throw on errors
> }
>
> template<>
> class basic_client<persistent_connections_tag, 1, 0> {
>   // implement a HTTP 1.0 client that supports persistent connections
> }
>
> Internally in all these specializations, you can pretty much do
> whatever you want. ;-)
>
> Then from there (and this approach) we can essentially write unit
> tests that make sure the implementations of the specifializations do
> what they're meant to do, and then we can look into how we can merge
> the current implementation of the basic_client to accomodate or even
> leverage the work you've done into the trunk. Maybe that would then
> get us release 0.4 having an HTTP 1.1 client available. :D
>
> How does that sound to you?
>
>   
I'll look into it at the wrapper class level. I'm content with the 
current rfc family tree, from which is growth is easy, however those 
could be further decomposed and "infused" with tags to configure 
different client behavior as needed by the basic_client and wrapper.

John

Re: [cpp-netlib-devel] soliciting ideas concerning client errors

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

On Wed, Jan 14, 2009 at 6:03 AM, John P. Feltz <jf...@ov...> wrote:
> Dean Michael Berris wrote:
>>
>> I agree that based on experience there aren't strictly 1.0 or 1.1
>> clients -- but the original intent of the library was to keep it
>> simple: so simple in fact that much of the nuances of the HTTP
>> protocol are hidden from the user. The aim is not to treat the users
>> as "stupid" but to give them a consistent and simple API from which
>> they can write their more important application logic around.
>>
>>
>
> I'm not suggesting getting rid of this simple API. rfc based policies
> are crucial as a foundation for defining client behavior at certain
> level. I'm suggesting that level to be at the implementation. A wrapper
> can be provided with certain predefined options, be those polices or
> non-policies to do what was the original design goal for the client class.
>

Ok.

How do you see this wrapper helping keep the API simple then?

>> I appreciate the idea of using policies, but the idea of the policies
>> as far as generic programming and design goes allows for well-defined
>> points of specialization. Let me try an example (untested):
>>
>> template <
>>   class Tag,
>>   class Policies,
>>   unsigned version_major,
>>   unsigned version_minor
>>
>> class basic_client : mpl:inherit_linearly<Policies>::type {
>>   private:
>>     typedef mpl:inherit_linearly<Policies>::type base;
>>   // ...
>>   basic_response<Tag> get(basic_request<Tag> const & request) {
>>     shared_ptr<socket> socket_ = base::init_connection(request);
>>     return base::perform_request(request, "GET");
>>   }
>> }
>> whatever implementation of init_connection is available to the
>> available policies. Of course this assumes that the policies used are
>> orthogonal. Design-wise it would be nice to enforce at compile-time
>> the concepts of the policies valid for the basic_client, but that's
>> for later. ;)
>>
>
> Of the necessary concerns, I see the need to provide one for supplying
> the resolved, the sockets, and logic governing both. These seem
> nonorthogonal, and so facading is more appropriate for right now.
> Additionally, I don't write code through the lens of a policy based
> strategy until I've seen what the implementation requires.
>

Great. So what about nested policies?

management_policy<resolver_policy, socket_policy>

Where you have many management policies:

persistent_management_policy
strict_http_1_1_management_policy
proxy_aware_http
...

And many resolver policies

async_resolver_policy
sync_resolver_policy
...

And socket creation policies

sync_connect_policy
async_connect_policy
timeout_policy
...

?

>> The lack of an existing HTTP Client that's "really 1.0" or "really
>> 1.1" is not an excuse to come up with one. ;-)
>>
>
> I'm sure users wishing to optimize requests to legacy servers or servers
> which do not follow a complete 1.1 spec will find that rather
> frustrating. Especially since it something so simple to design for (see
> branch).
>

True, but notice that HTTP 1.0 servers which return HTTP 505 errors
that says it doesn't support HTTP 1.1 should allow the user to use the
appropriate client. This logic should be provided by the user of the
library, instead of the library writers -- where our aim is to provide
a reasonably compliant *and* simple API.

This is similar to the discussion about providing a public method
'perform' with a string provided as the action and my stance doesn't
change -- the point of an HTTP client is to be reasonably compliant to
the HTTP 1.0/1.1 spec, and thus only supported or "standard" methods
are supported.

So having something like:

struct http_client_base {
  http_client_base() {}
  virtual http::response get(http::request const & request);
}

struct http_1_1_client : http_client_base {
  http_1_1_client() {}
  http::response get(http::request const & request) { return
client_.get(request); }
  private:
    basic_client<http::message_tag, 1, 1> client_;
}

struct http_1_0_client : http_client_base {
  http_1_0_client() {}
  http::response get(http::request const & request) { return
client_.get(request); }
  private:
    basic_client<http::message_tag, 1, 0> client_;
}

That's written by the user of the library to support his use case of a
dynamically determined HTTP 1.0 and HTTP 1.1 client would not be
entirely impossible. OTOH, the responsibility of
basic_client<http::message_tag, 1, 0> would be to provide a
sufficiently compliant HTTP 1.0 client, and
basic_client<http::message_tag, 1, 1> would be to provide a
sufficiently compliant HTTP 1.1 client.

>> So what I'm saying really is, we have a chance (since this is
>> basically from scratch anyway) to be able to do something that others
>> have avoided: writing a simple HTTP client which works when you say
>> it's really 1.0, or that it's really 1.1 -- in the simplest way
>> possible. The reason they're templates are that if you don't like how
>> they're implemented, then you can specialize them to your liking. :-)
>>
>
> This is a fine goal, however assuming that the simplest design will
> address what I believe to be all the complex concerns is flawed. Let us
> solve the complex issues _first_, then simplify. There is nothing wrong
> with the basic_clients API in principle, though I think this should
> address complex users needs first and so delegation of that class to
> single request processing + a wrapper incorporating certain policies
> with predefined behavior is the best course for now.
>

I still don't see how complex really the concerns are.

If you're worried about unrecoverable errors, then you have exceptions
-- which is perfectly fine. I would even go farther and say we should
have special exception types to denote different types of exceptions
all deriving from std::runtime_error.

If you're worried about unrecoverable errors *and* you don't want
exceptions, you'll use the signature I've shown below. I might even go
and change the signature from

  tuple<basic_response<Tag>, error_code> get(basic_request<Tag> const
& request, no_throw_t(*)());

to something like

  tuple<optional<basic_response<Tag> >, optional<error_code> >
get(basic_request<Tag> const & request, no_throw_t(*)());

And enforce that either the response is not defined if error_code is
defined, or that basic_response<Tag> was defined if error_code is not
defined. I might even explore the possibility of using a
boost::variant, but I'm not too comfortable with the usage semantics
of variants. This might require some more thought on my part, but I'm
thinking aloud on how I'll address the conveyance of errors from the
client side.

>>
>> Actually when it comes to error-handling efficiency (i.e. avoiding
>> exceptions which I think are perfectly reasonable to have), I would
>> have been happy with something like this:
>>
>> template <...>
>> class basic_client {
>>   basic_response<Tag> get(basic_request<Tag> const & request);
>>   tuple<basic_response<Tag>, error_code> get(basic_request<Tag> const
>> & request, no_throw_t(*)());
>> }
>>
>> This way, if you call 'get' with the nothrow function pointer
>> argument, then you've got yourself covered -- and instead of a
>> throwing implementation, the client can return a pair containing the
>> (possibly empty) basic_response<Tag> and an (possibly
>> default-constructed) error_code.
>>
>
> I don't see where function pointers belong in a client which intends to
> remain simple. I'm also against a no-throw parameter because it is less
> explicit. If an exception is thrown then the user knows there's an issue
> and a valid response was not returned. If a response is returned either
> way, than it is easier for the user to miss.
>

This is how you use that signature (with the unused function pointer):

http::client client_;
http::request request("http://www.booost.org");
http::response response;
boost::system::error_code error_code;
tie(response, error_code) = client_.get(request, http::nothrow);

The http::nothrow function would be defined as such:

struct no_throw_t;

inline no_throw_t no_throw() {
  return no_throw_t();
}

struct no_throw_t {
  private:
    no_throw_t();
    friend no_throw_t no_throw();
};

:-)

>>
>> Actually, there's nothing in the HTTP 1.0 spec that says a response
>> that's HTTP 1.x where x != 0 is an invalid response. There's also
>> nothing in the spec that says that HTTP 1.1 requests cannot be
>> completed when the HTTP 1.0 response is received.
>>
>
> These are cases that I'm not concerned with.
>

Okay, but if you were concerned with compliance when it comes to
things like persistent connections, request pipelining support, and
streaming encodings, maybe making them specializations of the basic
client using a different tag on different HTTP version numbers would
be something you'd like to explore. :-)

>>> I have no comment regarding a-sync usage as I've not looked into that
>>> issue in depth, I've only tried to make existing policy functions as
>>> re-usable as possible for that case.
>>>
>>
>> Which I think is the wrong approach if you ask me.
>>
>>
> By existing I was referring to things like stateless items such as
> append_* in the branch. If these can't be used asynchronously I would be
> curious as to why. I've expended no other effort in regards to this.

Ok. :)


>>
>> I think if you really want to be able to decompose the client into
>> multiple orthogonal policies, you might want to look into introducing
>> more specific extension points in the code instead of being hampered
>> by earlier (internal) design decisions. ;)
>>
>>
>
> I am growing tired of discussing this and would prefer to just get on
> with implementing _something_ in the branch. After tomorrow I'll be
> going back to my day job and time for working on this will be limited
> and I don't want to spend that time debating design decisions in which
> there can be very little compromise.
>

Okay.

At any rate, since the basic_client is meant to be the "world-facing"
API, it's not entirely impossible to write auxiliary classes that were
used by a specialization of the basic_client with a different tag.
What I mean by this is that for example, you can have a different tag
and a different set of (new) traits and accessors from which you can
design the basic_client specialization around.

struct non_throwing_tag;
struct persistent_connections_tag;

namespace triats {
  template <class T>
  struct http_tag;

  template <>
  struct http_tag<non_throwing_tag> {
    typedef http::message_tag type;
  };

  template <>
  struct http_tag<persistent_connections_tag> {
    typedef http::message_tag type;
  };
}

template<>
class basic_client<non_throwing_tag, 1, 0> {
  // different API of a client that doesn't throw on errors
}

template<>
class basic_client<persistent_connections_tag, 1, 0> {
  // implement a HTTP 1.0 client that supports persistent connections
}

Internally in all these specializations, you can pretty much do
whatever you want. ;-)

Then from there (and this approach) we can essentially write unit
tests that make sure the implementations of the specifializations do
what they're meant to do, and then we can look into how we can merge
the current implementation of the basic_client to accomodate or even
leverage the work you've done into the trunk. Maybe that would then
get us release 0.4 having an HTTP 1.1 client available. :D

How does that sound to you?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.