Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Dean M. B. <mik...@gm...> - 2010-11-14 06:51:13
|
On Sat, Nov 13, 2010 at 4:42 PM, qjmann <sou...@gm...> wrote:
>
> Thank's a lot, I used asynchronous tags, and now "client.get(request)"
> call is not blocking progpam's execution.
> In my application there will be a huge queue of URLs (from different
> hosts, it is just a crawler) and very limited set of requester objects
> (app must handle ~100 concurrent connections).
100 concurrent connections is easy to handle. But not with the current
implementation of the HTTP client.
>
> So, next trouble is how to check if client[i] has received the whole
> response and disconnected from server ("Connection: close" request
> header was used) or not. How to check this?
You cannot do that yet now.
I might implement a wrapper or a simple check on the response objects
to see whether the body part is done. It should be trivial to do but
I'm concentrating on the server side.
Maybe others on the list might want to implement this for the
asynchronous basic_response<Tag> overload where Tag is asynchronous?
*hint*. :)
> And additionally, how to
> pass callback handlers into client (or response maybe?) object?
> I have found nothing about this in documentation and in examples also.
>
These are not possible yet. As I've said earlier, this will be made
possible in a later release, potentially 0.9, which will come after
0.8 (scheduled for release next week).
HTH
--
Dean Michael Berris
deanberris.com
|
|
From: qjmann <sou...@gm...> - 2010-11-13 08:42:26
|
> > On Sat, Nov 13, 2010 at 3:32 AM, qjmann<sou...@gm... <mailto:sou...@gm...>> wrote: > > Documentation contains example HTTP client, but I see it works in blocking > > mode: > > > > http_client::response response = client.get(request) > > > > - this call will stop program execution while waiting for server's response. > > Not if http_client is a typedef like: > > typedef boost::network::http::basic_client< > boost::network::http::tags::http_async_8bit_udp_resolve > , 1, 0> http_client; > > > Is it possible to perform multiple concurrent requests with cpp_netlib > > without spawning multiple threads, as it can be done with ASIO asynchronous > > sockets? > > Yes, use the asynchronous tags for the http_client. This will use > futures underneath. > > In a later release there will be a change in the interface for an > asynchronous HTTP client that will take in a function to handle > incoming data from a request -- most probably will follow the same > interface that the async HTTP server in 0.8-devel will, I still > haven't decided yet. > > > > > 1) Create single io_service object > > 2) Create and initialize client objects set (all attached to io_service > > object just created) > > 3) Call io_service.poll() > > 4) Check client objects for responses received > > 5) If some responses has not been received yet, then goto step 3 > > > > No need for polling really, a callback mechanism or the current > futures-based implementation should suffice for most cases. > > HTH > > -- > Dean Michael Berris > deanberris.com > Thank's a lot, I used asynchronous tags, and now "client.get(request)" call is not blocking progpam's execution. In my application there will be a huge queue of URLs (from different hosts, it is just a crawler) and very limited set of requester objects (app must handle ~100 concurrent connections). So I want to implement a loop: while(/* queue has urls */) { for(/* loop through client objects set */) if(/* client[i] received the whole response */) { /* get response body */ /* get new URL from queue */ /* set new URL for client[i] request */ /* client[i].get(request) */ } } So, next trouble is how to check if client[i] has received the whole response and disconnected from server ("Connection: close" request header was used) or not. How to check this? And additionally, how to pass callback handlers into client (or response maybe?) object? I have found nothing about this in documentation and in examples also. |
|
From: Dean M. B. <mik...@gm...> - 2010-11-12 20:53:48
|
On Sat, Nov 13, 2010 at 3:32 AM, qjmann <sou...@gm...> wrote:
> Documentation contains example HTTP client, but I see it works in blocking
> mode:
>
> http_client::response response = client.get(request)
>
> - this call will stop program execution while waiting for server's response.
Not if http_client is a typedef like:
typedef boost::network::http::basic_client<
boost::network::http::tags::http_async_8bit_udp_resolve
, 1, 0> http_client;
> Is it possible to perform multiple concurrent requests with cpp_netlib
> without spawning multiple threads, as it can be done with ASIO asynchronous
> sockets?
Yes, use the asynchronous tags for the http_client. This will use
futures underneath.
In a later release there will be a change in the interface for an
asynchronous HTTP client that will take in a function to handle
incoming data from a request -- most probably will follow the same
interface that the async HTTP server in 0.8-devel will, I still
haven't decided yet.
>
> 1) Create single io_service object
> 2) Create and initialize client objects set (all attached to io_service
> object just created)
> 3) Call io_service.poll()
> 4) Check client objects for responses received
> 5) If some responses has not been received yet, then goto step 3
>
No need for polling really, a callback mechanism or the current
futures-based implementation should suffice for most cases.
HTH
--
Dean Michael Berris
deanberris.com
|
|
From: qjmann <sou...@gm...> - 2010-11-12 19:32:42
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#ffffff"> <div class="post-text"> <p><b><strong></strong></b>Documentation contains example <strong>HTTP client</strong>, but I see it works in <strong>blocking mode</strong>:</p> <pre class="prettyprint"><code><span class="pln">http_client</span><span class="pun">::</span><span class="pln">response response </span><span class="pun">=</span><span class="pln"> client</span><span class="pun">.</span><span class="kwd">get</span><span class="pun">(</span><span class="pln">request</span><span class="pun">)</span><span class="pln"></span></code></pre> <p>- this call will stop program execution while waiting for server's response. Is it possible to perform <strong>multiple concurrent requests with cpp_netlib</strong> without spawning multiple threads, as it can be done with ASIO asynchronous sockets? I mean a non-blocking manner, something like this:<br> </p> <p>1) Create single io_service object<br> 2) Create and initialize client objects set (all attached to io_service object just created)<br> 3) Call io_service.poll()<br> 4) Check client objects for responses received<br> 5) If some responses has not been received yet, then goto step 3<br> </p> </div> </body> </html> |
|
From: Dean M. B. <mik...@gm...> - 2010-11-09 17:27:06
|
On Tue, Nov 9, 2010 at 10:40 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote on Tuesday, November 09, 2010 >> >> Have a great day guys and I hope this helps! :D > > Great news, Dean! > Glad you liked the news Erik! :) -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-11-09 14:40:14
|
Dean Michael Berris wrote on Tuesday, November 09, 2010 > > I just wanted to give a heads up that the asynchronous HTTP server > implementation I've just pushed to the HEAD of 0.8-devel can now > handle a benchmarked 2800 requests per second, serving up 10kb worth > of Lorem Ipsum text. I benchmarked it with Apache Bench (ab) on Linux > with the libs/network/test/http_async_server.cpp built with clang 2.9 > (trunk). > > If you have time and/or more powerful machines, it would be great if > you can test it out as well. I haven't done any testing on > over-the-network requests, and I'll try to do that in a few minutes. > > This goes without saying though that it looks like the 0.8-devel > branch is finally ready for merging to master, and the beta/RC testing > could commence soon. > > Questions about the implementation would be entertained by yours truly > so ask away. :) > > Have a great day guys and I hope this helps! :D Great news, Dean! Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-11-09 07:41:41
|
Hi Guys, I just wanted to give a heads up that the asynchronous HTTP server implementation I've just pushed to the HEAD of 0.8-devel can now handle a benchmarked 2800 requests per second, serving up 10kb worth of Lorem Ipsum text. I benchmarked it with Apache Bench (ab) on Linux with the libs/network/test/http_async_server.cpp built with clang 2.9 (trunk). If you have time and/or more powerful machines, it would be great if you can test it out as well. I haven't done any testing on over-the-network requests, and I'll try to do that in a few minutes. This goes without saying though that it looks like the 0.8-devel branch is finally ready for merging to master, and the beta/RC testing could commence soon. Questions about the implementation would be entertained by yours truly so ask away. :) Have a great day guys and I hope this helps! :D -- Dean Michael Berris deanberris.com |
|
From: Steve O. <st...@so...> - 2010-11-08 15:52:37
|
----- "Dean Michael Berris" <mik...@gm...> wrote: > On Mon, Nov 8, 2010 at 11:24 PM, Steve Obbayi <st...@so...> > wrote: > > Do I go ahead and fork from mikhailberis / cpp-netlib because > cpp-netlib / cpp-netlib doesnt seem to have the > > 0.8-devel branch > > > > Yes, Steve, please fork from mikhailberis/cpp-netlib -- that's the > active development repository. Once things stabilize there from my > repo that's when I merge things over to the official repo. > > Also, please don't top post. :) > > Thanks! :D > > -- > Dean Michael Berris > deanberris.com > Okay great, thanks :) -- Steve Obbayi Software Developer |
|
From: Dean M. B. <mik...@gm...> - 2010-11-08 15:34:38
|
On Mon, Nov 8, 2010 at 11:24 PM, Steve Obbayi <st...@so...> wrote: > Do I go ahead and fork from mikhailberis / cpp-netlib because cpp-netlib / cpp-netlib doesnt seem to have the > 0.8-devel branch > Yes, Steve, please fork from mikhailberis/cpp-netlib -- that's the active development repository. Once things stabilize there from my repo that's when I merge things over to the official repo. Also, please don't top post. :) Thanks! :D -- Dean Michael Berris deanberris.com |
|
From: Steve O. <st...@so...> - 2010-11-08 15:24:48
|
Do I go ahead and fork from mikhailberis / cpp-netlib because cpp-netlib / cpp-netlib doesnt seem to have the 0.8-devel branch Steve Obbayi Software Developer ----- Original Message ----- From: "Dean Michael Berris" <mik...@gm...> To: "C++ Networking Library Developers Mailing List" <cpp...@li...> Sent: Monday, November 8, 2010 8:19:14 AM GMT -05:00 US/Canada Eastern Subject: [cpp-netlib-devel] 0.8 release slips, opting to be cautious with asynchronous server implementation Hi Everyone, Title says much of it, but the HEAD of 0.8-devel now has a complete but untested implementation of the asynchronous server template and connection handler. There's a lot of code that needs testing, and I'd be happy if people can check that out and see whether they can find anything glaringly wrong (and of course let me know about it). The whole test suite builds, but I haven't run the tests for the asynchronous server implementation. If anybody can test that in isolation given the example test in libs/network/test/http_async_server.hpp that would be greatly appreciated. Have a good day everyone and I hope this helps. PS. My updated estimate on the 0.8 release moves from 1st week of November to 3rd week of November. Hopefully enough people try it out and report issues early on in the process. ;) -- Dean Michael Berris deanberris.com ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Cpp-netlib-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel |
|
From: Dean M. B. <mik...@gm...> - 2010-11-08 13:19:41
|
Hi Everyone, Title says much of it, but the HEAD of 0.8-devel now has a complete but untested implementation of the asynchronous server template and connection handler. There's a lot of code that needs testing, and I'd be happy if people can check that out and see whether they can find anything glaringly wrong (and of course let me know about it). The whole test suite builds, but I haven't run the tests for the asynchronous server implementation. If anybody can test that in isolation given the example test in libs/network/test/http_async_server.hpp that would be greatly appreciated. Have a good day everyone and I hope this helps. PS. My updated estimate on the 0.8 release moves from 1st week of November to 3rd week of November. Hopefully enough people try it out and report issues early on in the process. ;) -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-11-07 02:20:16
|
On Sun, Nov 7, 2010 at 2:52 AM, Jeroen Habraken <vex...@gm...> wrote: > Hi guys, > > I've got to start writing documentation for construe_cast, Cool! :) I'll look forward to that, and eventually porting all the lexical_cast<> stuff in cpp-netlib to construe_cast instead. :D > and am > wondering if you've got any tips. Is boostbook the way to go, or > should I use something else? > Since you intend to make it part of Boost, I would suggest you write the documentation in either RST or Quickbook. Since you're starting from scratch I would suggest you go the RST route. You can look at Sphinx as well as the Boost.Build extensions to support RST processing to turn out HTML documentation. > Regards, HTH -- Dean Michael Berris deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-11-06 18:53:02
|
Hi guys, I've got to start writing documentation for construe_cast, and am wondering if you've got any tips. Is boostbook the way to go, or should I use something else? Regards, Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-11-06 13:34:26
|
On Wed, Nov 3, 2010 at 7:40 PM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > On 3 November 2010 11:22, Dean Michael Berris <mik...@gm...> > wrote: >> >> Can you say what compiler you're using? Judging from the environment >> and the error messages it looks like you're using GCC on Linux -- any >> specific version number? > > D'oh, yeah its GCC 4.4 on Linux. > Those are fixed now on GCC 4.4 and GCC 4.5. HTH -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-11-04 11:46:55
|
On Wed, Nov 3, 2010 at 7:56 PM, Glyn Matthews <gly...@gm...> wrote: > Hi, > > On 3 November 2010 11:22, Dean Michael Berris <mik...@gm...> > wrote: >> >> >> >> >> 4. There's already a skeleton/outline for the documentation of the >> >> HTTP client and HTTP server interfaces. A reference manual is sorely >> >> lacking in the documentation, and it would be good for others to get >> >> their hands dirty with this one. I look forward to getting pull >> >> requests for the documentation from those who would want to contribute >> >> in this regard. :) >> > >> > Reference manual and examples :) we are still example poor at the >> > moment. >> > >> >> Yeah, I agree. We really need more feedback on the documentation -- >> although people seem to be alright with looking at the examples and >> running away with those, however poor the examples are. :D >> >> Although the reference manual would be great to write, I'll need help >> with making progress in that front. :) > > I think we ought to make use of the Github wiki for this: > http://github.com/cpp-netlib/cpp-netlib/wiki Yeah, can you start with the outline that I've already provided in the RST? I know tracing what the public interface of the client and the messages aren't straightforward with all the layers of inheritance that's been introduced already, but a good start would be looking at the client facade for the supported APIs. -- Dean Michael Berris deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-11-03 11:56:20
|
Hi, On 3 November 2010 11:22, Dean Michael Berris <mik...@gm...>wrote: > > >> > >> 4. There's already a skeleton/outline for the documentation of the > >> HTTP client and HTTP server interfaces. A reference manual is sorely > >> lacking in the documentation, and it would be good for others to get > >> their hands dirty with this one. I look forward to getting pull > >> requests for the documentation from those who would want to contribute > >> in this regard. :) > > > > Reference manual and examples :) we are still example poor at the moment. > > > > Yeah, I agree. We really need more feedback on the documentation -- > although people seem to be alright with looking at the examples and > running away with those, however poor the examples are. :D > > Although the reference manual would be great to write, I'll need help > with making progress in that front. :) > I think we ought to make use of the Github wiki for this: http://github.com/cpp-netlib/cpp-netlib/wiki<https://github.com/cpp-netlib/cpp-netlib/wiki> G |
|
From: Glyn M. <gly...@gm...> - 2010-11-03 11:41:02
|
Hi Dean, On 3 November 2010 11:22, Dean Michael Berris <mik...@gm...>wrote: > > On Tue, Nov 2, 2010 at 5:07 AM, Glyn Matthews <gly...@gm...> > wrote: > > Hi Dean, > > > > On 30 October 2010 17:09, Dean Michael Berris <mik...@gm...> > > wrote: > >> > >> 2. I'm close to finishing the implementation details of the > >> asynchronous HTTP connection. This is on target for the 1st week of > >> November deadline, so I'm confident we can ship the next release by > >> the end of that week. > > > > I get this error message when compiling: > > Can you say what compiler you're using? Judging from the environment > and the error messages it looks like you're using GCC on Linux -- any > specific version number? > D'oh, yeah its GCC 4.4 on Linux. > > What the... Why doesn't clang complain about this and does the right > thing? Let me check to see why this issue comes up. I'll try with GCC > 4.5 and GCC 4.4. > > > There are other open issues on github reporting compilation failures for > > other platforms too. > > > > Yeah, thanks for those. I'll respond to Christian Henning on the > Boost-Users list about his issues. > > Thanks, Glyn |
|
From: Steve O. <st...@so...> - 2010-11-03 10:45:37
|
In that case congrats are in order. Congratulations. Great milestone there Steve Obbayi SKYPE: sobbayi Software Developer ----- Original Message ----- From: "Dean Michael Berris" <mik...@gm...> To: "C++ Networking Library Developers Mailing List" <cpp...@li...> Sent: Wednesday, November 3, 2010 6:22:00 AM GMT -05:00 US/Canada Eastern Subject: Re: [cpp-netlib-devel] 0.8-devel progress, more async HTTP server handler goodness Hey Guys! Aaaaaaaaaaand... I'm back! Earlier today was my daughter's first birthday celebration, so that marks the end of my vacation. Hopefully I'll get back to the hacking in the next couple days for the finishing touches. On Tue, Nov 2, 2010 at 5:07 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > On 30 October 2010 17:09, Dean Michael Berris <mik...@gm...> > wrote: >> >> 2. I'm close to finishing the implementation details of the >> asynchronous HTTP connection. This is on target for the 1st week of >> November deadline, so I'm confident we can ship the next release by >> the end of that week. > > I get this error message when compiling: Can you say what compiler you're using? Judging from the environment and the error messages it looks like you're using GCC on Linux -- any specific version number? Also, I'm being bitten by things like these: ... >mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29: > error: a call to a constructor cannot appear in a constant-expression Which is not right because I don't use * in a constant-expression... I'll look at that line again tomorrow. ... > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:251: > error: no matching function for call to ‘min(size_t&, long unsigned int)’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:267: > error: no matching function for call to ‘min(size_t&, long unsigned int)’ Which looks like I just have to initialize a static local size_t to hold the value of the macro. This type-specificity is actually really hard to see -- but Clang seems to be able to rightly compile two types of being `unsigned long int` (where std::size_t is also an unsigned long int). > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:20: > error: declaration of ‘typedef struct > boost::network::http::response_header<Tag> > boost::network::http::async_server_base<Tag, Handler>::response_header’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/header/name.hpp:14: > error: changes meaning of ‘response_header’ from ‘struct > boost::network::http::response_header<Tag>’ This is also odd because response_header is a local typedef in the async_server_base struct -- it doesn't change the meaning of the earlier declared response_header template in the namespace scope. This looks like a misinterpretation of the standard on the compiler's part IMO. It's easy to fix although it's perfectly standard C++ as far as I understand it. I may be wrong though. ... > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94: > error: in call to ‘find_if’ > /home/gmatthew/Projects/boost_1_43_0/boost/mpl/find_if.hpp:32: error: > argument dependent lookup finds ‘template<class Sequence, class Predicate> > struct boost::mpl::find_if’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94: > error: in call to ‘find_if’ What the... Why doesn't clang complain about this and does the right thing? Let me check to see why this issue comes up. I'll try with GCC 4.5 and GCC 4.4. > There are other open issues on github reporting compilation failures for > other platforms too. > Yeah, thanks for those. I'll respond to Christian Henning on the Boost-Users list about his issues. >> >> 4. There's already a skeleton/outline for the documentation of the >> HTTP client and HTTP server interfaces. A reference manual is sorely >> lacking in the documentation, and it would be good for others to get >> their hands dirty with this one. I look forward to getting pull >> requests for the documentation from those who would want to contribute >> in this regard. :) > > Reference manual and examples :) we are still example poor at the moment. > Yeah, I agree. We really need more feedback on the documentation -- although people seem to be alright with looking at the examples and running away with those, however poor the examples are. :D Although the reference manual would be great to write, I'll need help with making progress in that front. :) >> >> So that's it for now, I'll be in holiday mode starting tomorrow Oct 31 >> until Nov 2 (here in the Philippines). I'll be online briefly in the >> morning Philippine time to check mail before I head on to my home >> town, so if you have any questions you need answered before Wednesday >> (PHT) please ask away so I can respond quickly. :) > > Have a relaxing holiday and I hope you don't pay attention to these mails > before you return :) Thanks Glyn! It's going to be hacking days for me starting tomorrow. For now the email backlog is giving me the heebeejeebee's and I'm longing for Inbox 0 again. :) I better get cracking on these emails now. :D More from me later! -- Dean Michael Berris deanberris.com ------------------------------------------------------------------------------ Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov _______________________________________________ Cpp-netlib-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel |
|
From: Dean M. B. <mik...@gm...> - 2010-11-03 10:22:27
|
Hey Guys! Aaaaaaaaaaand... I'm back! Earlier today was my daughter's first birthday celebration, so that marks the end of my vacation. Hopefully I'll get back to the hacking in the next couple days for the finishing touches. On Tue, Nov 2, 2010 at 5:07 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > On 30 October 2010 17:09, Dean Michael Berris <mik...@gm...> > wrote: >> >> 2. I'm close to finishing the implementation details of the >> asynchronous HTTP connection. This is on target for the 1st week of >> November deadline, so I'm confident we can ship the next release by >> the end of that week. > > I get this error message when compiling: Can you say what compiler you're using? Judging from the environment and the error messages it looks like you're using GCC on Linux -- any specific version number? Also, I'm being bitten by things like these: ... >mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29: > error: a call to a constructor cannot appear in a constant-expression Which is not right because I don't use * in a constant-expression... I'll look at that line again tomorrow. ... > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:251: > error: no matching function for call to ‘min(size_t&, long unsigned int)’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:267: > error: no matching function for call to ‘min(size_t&, long unsigned int)’ Which looks like I just have to initialize a static local size_t to hold the value of the macro. This type-specificity is actually really hard to see -- but Clang seems to be able to rightly compile two types of being `unsigned long int` (where std::size_t is also an unsigned long int). > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:20: > error: declaration of ‘typedef struct > boost::network::http::response_header<Tag> > boost::network::http::async_server_base<Tag, Handler>::response_header’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/header/name.hpp:14: > error: changes meaning of ‘response_header’ from ‘struct > boost::network::http::response_header<Tag>’ This is also odd because response_header is a local typedef in the async_server_base struct -- it doesn't change the meaning of the earlier declared response_header template in the namespace scope. This looks like a misinterpretation of the standard on the compiler's part IMO. It's easy to fix although it's perfectly standard C++ as far as I understand it. I may be wrong though. ... > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94: > error: in call to ‘find_if’ > /home/gmatthew/Projects/boost_1_43_0/boost/mpl/find_if.hpp:32: error: > argument dependent lookup finds ‘template<class Sequence, class Predicate> > struct boost::mpl::find_if’ > /home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94: > error: in call to ‘find_if’ What the... Why doesn't clang complain about this and does the right thing? Let me check to see why this issue comes up. I'll try with GCC 4.5 and GCC 4.4. > There are other open issues on github reporting compilation failures for > other platforms too. > Yeah, thanks for those. I'll respond to Christian Henning on the Boost-Users list about his issues. >> >> 4. There's already a skeleton/outline for the documentation of the >> HTTP client and HTTP server interfaces. A reference manual is sorely >> lacking in the documentation, and it would be good for others to get >> their hands dirty with this one. I look forward to getting pull >> requests for the documentation from those who would want to contribute >> in this regard. :) > > Reference manual and examples :) we are still example poor at the moment. > Yeah, I agree. We really need more feedback on the documentation -- although people seem to be alright with looking at the examples and running away with those, however poor the examples are. :D Although the reference manual would be great to write, I'll need help with making progress in that front. :) >> >> So that's it for now, I'll be in holiday mode starting tomorrow Oct 31 >> until Nov 2 (here in the Philippines). I'll be online briefly in the >> morning Philippine time to check mail before I head on to my home >> town, so if you have any questions you need answered before Wednesday >> (PHT) please ask away so I can respond quickly. :) > > Have a relaxing holiday and I hope you don't pay attention to these mails > before you return :) Thanks Glyn! It's going to be hacking days for me starting tomorrow. For now the email backlog is giving me the heebeejeebee's and I'm longing for Inbox 0 again. :) I better get cracking on these emails now. :D More from me later! -- Dean Michael Berris deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-11-01 21:07:53
|
Hi Dean,
On 30 October 2010 17:09, Dean Michael Berris <mik...@gm...>wrote:
> Hi Everyone,
>
> I'd just like to give a quick update on the changes that are already
> in the 0.8-devel branch.
>
> 1. We already have a pretty stable interface for the asynchronous HTTP
> connection that handlers can deal with. I've tried documenting more of
> my thinking into the commit messages for the recent commits I've been
> pushing -- hopefully those make sense. ;)
>
> 2. I'm close to finishing the implementation details of the
> asynchronous HTTP connection. This is on target for the 1st week of
> November deadline, so I'm confident we can ship the next release by
> the end of that week.
>
I get this error message when compiling:
gmatthew@lola:~/Projects/cpp-netlib-mikhailberis/build$ make
Scanning dependencies of target cpp-netlib-hello_world
[ 5%] Building CXX object
libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/hello_world.cpp.o
In file included from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:11,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:9,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server.hpp:15,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/libs/network/test/hello_world.cpp:10:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29:
error: ‘*’ cannot appear in a constant-expression
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29:
error: a call to a constructor cannot appear in a constant-expression
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29:
error: template argument 1 is invalid
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/algorithms/linearize.hpp:29:
error: template argument 1 is invalid
In file included from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:9,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server.hpp:15,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/libs/network/test/hello_world.cpp:10:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:
In member function ‘void boost::network::http::async_connection<Tag,
Handler>::write_impl(Range, Callback)’:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:251:
error: no matching function for call to ‘min(size_t&, long unsigned int)’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_connection.hpp:267:
error: no matching function for call to ‘min(size_t&, long unsigned int)’
In file included from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server.hpp:15,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/libs/network/test/hello_world.cpp:10:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:
At global scope:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/async_server.hpp:20:
error: declaration of ‘typedef struct
boost::network::http::response_header<Tag>
boost::network::http::async_server_base<Tag, Handler>::response_header’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/header/name.hpp:14:
error: changes meaning of ‘response_header’ from ‘struct
boost::network::http::response_header<Tag>’
In file included from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_server.hpp:16,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server.hpp:14,
from
/home/gmatthew/Projects/cpp-netlib-mikhailberis/libs/network/test/hello_world.cpp:10:
/home/gmatthew/Projects/boost_1_43_0/boost/mpl/find_if.hpp: In member
function ‘void boost::network::http::sync_connection<Tag,
Handler>::handle_read_headers(const boost::system::error_code&, size_t)
[with Tag = boost::network::http::tags::http_server, Handler =
hello_world]’:
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:58:
instantiated from ‘void boost::network::http::sync_connection<Tag,
Handler>::start() [with Tag = boost::network::http::tags::http_server,
Handler = hello_world]’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_server.hpp:65:
instantiated from ‘void boost::network::http::sync_server_base<Tag,
Handler>::handle_accept(const boost::system::error_code&) [with Tag =
boost::network::http::tags::http_server, Handler = hello_world]’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_server.hpp:42:
instantiated from ‘boost::network::http::sync_server_base<Tag,
Handler>::sync_server_base(const typename
boost::network::string<Tag>::type&, const typename
boost::network::string<Tag>::type&, Handler&) [with Tag =
boost::network::http::tags::http_server, Handler = hello_world]’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server.hpp:44:
instantiated from ‘boost::network::http::server<Handler>::server(const
typename
boost::network::http::server_base<boost::network::http::tags::http_server,
Handler>::type::string_type&, const typename
boost::network::http::server_base<boost::network::http::tags::http_server,
Handler>::type::string_type&, Handler&) [with Handler = hello_world]’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/libs/network/test/hello_world.cpp:43:
instantiated from here
/home/gmatthew/Projects/boost_1_43_0/boost/mpl/find_if.hpp:32: error:
‘template<class Sequence, class Predicate> struct boost::mpl::find_if’ is
not a function,
/usr/include/c++/4.4/bits/stl_algo.h:4240: error: conflict with
‘template<class _IIter, class _Predicate> _IIter std::find_if(_IIter,
_IIter, _Predicate)’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94:
error: in call to ‘find_if’
/home/gmatthew/Projects/boost_1_43_0/boost/mpl/find_if.hpp:32: error:
argument dependent lookup finds ‘template<class Sequence, class Predicate>
struct boost::mpl::find_if’
/home/gmatthew/Projects/cpp-netlib-mikhailberis/boost/network/protocol/http/server/sync_connection.hpp:94:
error: in call to ‘find_if’
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp: At global
scope:
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp:208:
warning: ‘boost::system::system_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp:209:
warning: ‘boost::system::generic_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp:214:
warning: ‘boost::system::posix_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp:215:
warning: ‘boost::system::errno_ecat’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/system/error_code.hpp:216:
warning: ‘boost::system::native_ecat’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/asio/error.hpp:353: warning:
‘boost::asio::error::system_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/asio/error.hpp:355: warning:
‘boost::asio::error::netdb_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/asio/error.hpp:357: warning:
‘boost::asio::error::addrinfo_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/asio/error.hpp:359: warning:
‘boost::asio::error::misc_category’ defined but not used
/home/gmatthew/Projects/boost_1_43_0/boost/asio/error.hpp:361: warning:
‘boost::asio::error::ssl_category’ defined but not used
make[2]: ***
[libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/hello_world.cpp.o]
Error 1
make[1]: *** [libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/all]
Error 2
make: *** [all] Error 2
There are other open issues on github reporting compilation failures for
other platforms too.
>
> 3. There are a few issues I'd like to resolve as soon as I finish the
> HTTP server implementation that have something to do with the client
> interface among other things. It would be great if others can take a
> look at the list of issues at
> http://github.com/cpp-netlib/cpp-netlib/issues and vote on the ones
> you want me to finish first, or comment whether you want those fixed
> in 0.8. I'll try to squeeze in as many issue resolutions I can before
> I package the next release (not sure if it's 0.8 or 0.7.1 yet).
>
> 4. There's already a skeleton/outline for the documentation of the
> HTTP client and HTTP server interfaces. A reference manual is sorely
> lacking in the documentation, and it would be good for others to get
> their hands dirty with this one. I look forward to getting pull
> requests for the documentation from those who would want to contribute
> in this regard. :)
>
Reference manual and examples :) we are still example poor at the moment.
>
> So that's it for now, I'll be in holiday mode starting tomorrow Oct 31
> until Nov 2 (here in the Philippines). I'll be online briefly in the
> morning Philippine time to check mail before I head on to my home
> town, so if you have any questions you need answered before Wednesday
> (PHT) please ask away so I can respond quickly. :)
>
Have a relaxing holiday and I hope you don't pay attention to these mails
before you return :)
G
|
|
From: Dean M. B. <mik...@gm...> - 2010-10-30 15:09:31
|
Hi Everyone, I'd just like to give a quick update on the changes that are already in the 0.8-devel branch. 1. We already have a pretty stable interface for the asynchronous HTTP connection that handlers can deal with. I've tried documenting more of my thinking into the commit messages for the recent commits I've been pushing -- hopefully those make sense. ;) 2. I'm close to finishing the implementation details of the asynchronous HTTP connection. This is on target for the 1st week of November deadline, so I'm confident we can ship the next release by the end of that week. 3. There are a few issues I'd like to resolve as soon as I finish the HTTP server implementation that have something to do with the client interface among other things. It would be great if others can take a look at the list of issues at http://github.com/cpp-netlib/cpp-netlib/issues and vote on the ones you want me to finish first, or comment whether you want those fixed in 0.8. I'll try to squeeze in as many issue resolutions I can before I package the next release (not sure if it's 0.8 or 0.7.1 yet). 4. There's already a skeleton/outline for the documentation of the HTTP client and HTTP server interfaces. A reference manual is sorely lacking in the documentation, and it would be good for others to get their hands dirty with this one. I look forward to getting pull requests for the documentation from those who would want to contribute in this regard. :) So that's it for now, I'll be in holiday mode starting tomorrow Oct 31 until Nov 2 (here in the Philippines). I'll be online briefly in the morning Philippine time to check mail before I head on to my home town, so if you have any questions you need answered before Wednesday (PHT) please ask away so I can respond quickly. :) Have a great weekend everyone! I look forward to getting back into it by Nov 2. -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-10-29 07:39:57
|
Hi Guys, Aside from the earlier mentioned compile-time reduction techniques being used now in the HEAD of 0.8-devel, I'm also getting along fine on the asynchronous HTTP server part. Here's the top-level conceptual gist: 1. When a connection is accepted, all connection-related logic for asynchronous request processing is done at the connection level (nothing new here). 2. The connection will then schedule the handler function call in a thread pool that is passed to it by reference from the HTTP server. This function will take a request object (without a body) and a shared pointer to the connection that invoked it. 3. The handler can then schedule its own asynchronous calls like asynchronous reads, and perform asynchronous writes -- the reads will be handled in the io_service thread running the HTTP server, but the handler is invoked in the worker thread pool. Asynchronous writes will be queued by the connection -- a call to 'write' will require a Range, which will be linearized into a buffer (Boost.Array or a streambuf), then schedules an asynchronous write to the socket associated with the connection. This will change the requirement on the Handler to be passed by reference to the HTTP server. The signature of the handler function will take a `basic_request<http::tags::http_async_server> const &` and a `async_connection<http::tags::http_async_server, Handler> &`. There's an example of the new handler signature here: http://goo.gl/W9Rp HTH -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-10-28 09:08:15
|
On Thu, Oct 28, 2010 at 3:51 PM, Jeroen Habraken <vex...@gm...> wrote: > On 28 October 2010 05:28, Dean Michael Berris <mik...@gm...> wrote: >> >> Yeah, please go ahead and take these on -- Jeroen seems to be busy on >> the construe_cast front. I won't have enough time to manage both the >> server implementation (which has its beginning already in the branch) >> and refactoring the parsers until my personal deadline of first week >> November. :) > > Sorry you haven't heard from me in a while, I'm indeed up to my nose > in work (mostly school-related, I don't even have the time I want to > put into construe_cast). If you can get these fixed, please, by all > means have a go. I'll keep a closer eye on the mailing list, thus if > you have any questions you can fine me here :) > Thanks Jeroen for making your self available to the list. :) Let us know how we can help with construe_cast or even your school-related stuff, we just might be able to do something there. :D -- Dean Michael Berris deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-10-28 07:51:30
|
On 28 October 2010 05:28, Dean Michael Berris <mik...@gm...> wrote: > On Tue, Oct 26, 2010 at 6:14 PM, Glyn Matthews <gly...@gm...> wrote: >> >> On 26 October 2010 06:04, Dean Michael Berris <mik...@gm...> >> wrote: >>> >>> I'll be perfectly happy with releasing an improved server for 0.8 or >>> just calling it 0.7.1 might be better. I really want to see both the >>> improved MIME and XMPP implementations in cpp-netlib before we submit >>> for review/inclusion in Boost for December. >>> >> >> Will MIME be part of cpp-netlib? As I understood it, it was being developed >> separately. > > Yes and no -- Marshall and I have been talking about it and although > it will be submitted separately, it won't hurt to make it part of > cpp-netlib in the meantime and in releases we do make (much like it is > included now, albeit independent). > >> Also, for 0.8 I'd like to push for an effort fixes to #18 and #15: >> http://github.com/cpp-netlib/cpp-netlib/issues/#issue/18 >> http://github.com/cpp-netlib/cpp-netlib/issues/#issue/15 >> Maybe I ought to take this on if there are no other volunteers ... > > Yeah, please go ahead and take these on -- Jeroen seems to be busy on > the construe_cast front. I won't have enough time to manage both the > server implementation (which has its beginning already in the branch) > and refactoring the parsers until my personal deadline of first week > November. :) Sorry you haven't heard from me in a while, I'm indeed up to my nose in work (mostly school-related, I don't even have the time I want to put into construe_cast). If you can get these fixed, please, by all means have a go. I'll keep a closer eye on the mailing list, thus if you have any questions you can fine me here :) > Thanks Glyn! > > -- > Dean Michael Berris > deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-10-28 03:28:58
|
On Tue, Oct 26, 2010 at 6:14 PM, Glyn Matthews <gly...@gm...> wrote: > > On 26 October 2010 06:04, Dean Michael Berris <mik...@gm...> > wrote: >> >> I'll be perfectly happy with releasing an improved server for 0.8 or >> just calling it 0.7.1 might be better. I really want to see both the >> improved MIME and XMPP implementations in cpp-netlib before we submit >> for review/inclusion in Boost for December. >> > > Will MIME be part of cpp-netlib? As I understood it, it was being developed > separately. Yes and no -- Marshall and I have been talking about it and although it will be submitted separately, it won't hurt to make it part of cpp-netlib in the meantime and in releases we do make (much like it is included now, albeit independent). > Also, for 0.8 I'd like to push for an effort fixes to #18 and #15: > http://github.com/cpp-netlib/cpp-netlib/issues/#issue/18 > http://github.com/cpp-netlib/cpp-netlib/issues/#issue/15 > Maybe I ought to take this on if there are no other volunteers ... Yeah, please go ahead and take these on -- Jeroen seems to be busy on the construe_cast front. I won't have enough time to manage both the server implementation (which has its beginning already in the branch) and refactoring the parsers until my personal deadline of first week November. :) Thanks Glyn! -- Dean Michael Berris deanberris.com |
7 messages has been excluded from this view by a project administrator.
