cpp-netlib-devel — Developers Mailing List

[cpp-netlib-devel] Example hello_world_server.cpp broken in v0.8?

[Christoffer M. <Mol...@in...>]

Hi everyone,

I'm hitting the following compilation error using Visual Studio 2010 and Boost 1.45. The example compiles perfectly using v0.7, however.

1>------ Build started: Project: NetlibTest, Configuration: Debug Win32 ------
1>  hello_world_server.cpp
1>c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(28): error C2065: 'or_' : undeclared identifier
1>          c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(37) : see reference to class template instantiation 'boost::network::http::traits::version<Message>' being compiled
1>c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(29): error C2275: 'boost::network::is_sync<Message::tag>' : illegal use of this type as an expression
1>c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(32): error C2974: 'boost::mpl::if_' : invalid template argument for 'T1', type expected
1>          c:\greenfield\include\boost\mpl\if.hpp(56) : see declaration of 'boost::mpl::if_'
1>c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(35): error C2977: 'boost::mpl::if_' : too many template arguments
1>          c:\greenfield\include\boost\mpl\if.hpp(56) : see declaration of 'boost::mpl::if_'
1>c:\cpp-netlib-0.8\boost\network\protocol\http\message\traits\version.hpp(36): error C2143: syntax error : missing ',' before '>'
1>  Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:
1>  - add -D_WIN32_WINNT=0x0501 to the compiler command line; or
1>  - add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
1>  Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).

Looks like a using directive got lost on the way somewhere.

Best regards,
Christoffer M.

Re: [cpp-netlib-devel] The Compile-Time Issue: Boost.Variant

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

On Sun, Nov 28, 2010 at 1:53 PM, Dean Michael Berris
<mik...@gm...> wrote:
> On Sun, Nov 28, 2010 at 1:47 PM, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> I'll be pushing soon so expect a greatly reduced compile-time for the tests now.
>>
>
> Well, I jumped the gun on "greatly reduced". It's a little faster than
> usual. I keep forgetting that clang is just really way faster than
> GCC. But, it's niticeably quicker on GCC 4.5. Not sure with other
> compilers though. :D
>

And it's up, the relevant commit (with explanation) is here: http://goo.gl/jXPff

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Call For Help: Testers

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

On Sun, Nov 28, 2010 at 1:57 PM, Steve Obbayi <st...@so...> wrote:
>
> ----- "Dean Michael Berris" <mik...@gm...> wrote:
>
>> On Sun, Nov 28, 2010 at 1:32 PM, Steve Obbayi <st...@so...>
>> wrote:
>> >
>> > Hi Dean, still on vacation traveling quite a bit:) but this is
>> interesting stuff I am definitely eager
>> > to dig in from when I get home on Wednesday. Any particular
>> priorities/targets you'd prefer from the list?
>>
>> Thanks Steve!
>>
>> Testing on either Mac OSX or Windows with the native compilers there
>> would definitely be helpful.
>>
>> Looking forward to inputs/updates from others too!
>>
>> --
>> Dean Michael Berris
>> deanberris.com
>>
>
> I get back home on Wednesday so I will be able to do some tests on windows then with msvc 2010,
> and mingw too, then I'll let you know.
>

Great! Thanks Steve, looking forward to your experience with
cpp-netlib on those compilers. :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Call For Help: Testers

[Steve O. <st...@so...>]

----- "Dean Michael Berris" <mik...@gm...> wrote:

> On Sun, Nov 28, 2010 at 1:32 PM, Steve Obbayi <st...@so...>
> wrote:
> >
> > Hi Dean, still on vacation traveling quite a bit:) but this is
> interesting stuff I am definitely eager
> > to dig in from when I get home on Wednesday. Any particular
> priorities/targets you'd prefer from the list?
> 
> Thanks Steve!
> 
> Testing on either Mac OSX or Windows with the native compilers there
> would definitely be helpful.
> 
> Looking forward to inputs/updates from others too!
> 
> -- 
> Dean Michael Berris
> deanberris.com
> 

I get back home on Wednesday so I will be able to do some tests on windows then with msvc 2010,
and mingw too, then I'll let you know.

-- 
Steve Obbayi

SKYPE: sobbayi
http://sobbayi.com
http://blog.sobbayi.com

Re: [cpp-netlib-devel] The Compile-Time Issue: Boost.Variant

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

On Sun, Nov 28, 2010 at 1:47 PM, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Everyone,
>
> So today I revisited my implementation of the directives and it looks
> like using Boost.Variant in the implementation seems to be one of the
> biggest contributors to compile time -- well, second to Boost.Spirit
> -- and removing it from the directive implementations seems to be
> going well.
>
> I'll be pushing soon so expect a greatly reduced compile-time for the tests now.
>

Well, I jumped the gun on "greatly reduced". It's a little faster than
usual. I keep forgetting that clang is just really way faster than
GCC. But, it's niticeably quicker on GCC 4.5. Not sure with other
compilers though. :D

HTH!

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] The Compile-Time Issue: Boost.Variant

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

Hi Everyone,

So today I revisited my implementation of the directives and it looks
like using Boost.Variant in the implementation seems to be one of the
biggest contributors to compile time -- well, second to Boost.Spirit
-- and removing it from the directive implementations seems to be
going well.

I'll be pushing soon so expect a greatly reduced compile-time for the tests now.

Have a good one and I hope this helps! :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Call For Help: Testers

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

On Sun, Nov 28, 2010 at 1:32 PM, Steve Obbayi <st...@so...> wrote:
>
> Hi Dean, still on vacation traveling quite a bit:) but this is interesting stuff I am definitely eager
> to dig in from when I get home on Wednesday. Any particular priorities/targets you'd prefer from the list?

Thanks Steve!

Testing on either Mac OSX or Windows with the native compilers there
would definitely be helpful.

Looking forward to inputs/updates from others too!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Call For Help: Testers

[Steve O. <st...@so...>]

----- "Dean Michael Berris" <mik...@gm...> wrote:

> Hi Everyone,
> 
> Much is going to happen in cpp-netlib with 0.9. Here's a list of
> things I have on my hit-list (some carried-over from 0.8):
> 
> ---8<--
> Improve the Client and Server interfaces. Explore the following:
> 
> • Support Boost.Iostreams for Body content in Client and Server APIs
> • Client-Specific Enhancements
> ∘ Cookie Management
> ∘ Proxy Support
> • Easy Tag Mixing (PP based Tag Building)
> • Boost.Parameter interface for functions and constructors
> • Server-Specific Enhancements
> ∘ Initial Service Framework
> ∘ Web Development Framework
> • ESMTP Support
> ∘ ESMTP 1.0 Client
> 
> Next Steps:
>   Document the HTTP Connection concept
>   Document the thread pool concept
>   Implement space-efficient HTTP request/response types
>   Make request/response types PODs
>   Support ranges to be made part of the message types
>   Boost.Parameter in Templates for Client and Server
> ---8<--
> 
> That said, I would really appreciate it if people can help test the
> library on various platforms. I'll be making lots of changes -- expect
> some interface breaking changes, especially on the client side,
> because the current interface is very limited.
> 
> Let me know if you need any specific information, but just people
> testing with bjam and/or cmake on their platforms would very much be
> appreciated. This is in the meantime until I get to a point where I
> can dedicate enough machine power to do the same.
> 
> Have a good one and I hope to hear from you soon!
> 
> --
> Dean Michael Berris
> deanberris.com


Hi Dean, still on vacation traveling quite a bit:) but this is interesting stuff I am definitely eager
to dig in from when I get home on Wednesday. Any particular priorities/targets you'd prefer from the list? 
-- 
Steve Obbayi
Software Developer

[cpp-netlib-devel] Call for Help: Website

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

Hi Everyone!

It's that time again and I would really appreciate contributions to
the website's design. I'm thinking of separating the website's front
page from the documentation's front-page.

As it stands right now, starting with 0.8, I've made version-specific
directories in cpp-netlib.github.com. That means when you go to
http://cpp-netlib.github.com/0.8 you will find the documentation for
the 0.8 release. I'm looking at retro-actively adding the 0.7
documentation to its own directory so that we don't miss versions of
the doc online.

That said, I'm looking for people who have time to spare and some
talent with design and layout to help out in the website. It's just
static HTML for now, but I'm looking at maybe using either Jekyll or
something else for the site. Sphinx works great for the documentation,
I'm not so happy with it for building static websites though
especially for a website. Suggestions would be most appreciated.

Have a good one and I look forward to help soon!

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] Call For Help: Testers

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

Hi Everyone,

Much is going to happen in cpp-netlib with 0.9. Here's a list of
things I have on my hit-list (some carried-over from 0.8):

---8<--
Improve the Client and Server interfaces. Explore the following:

• Support Boost.Iostreams for Body content in Client and Server APIs
• Client-Specific Enhancements
∘ Cookie Management
∘ Proxy Support
• Easy Tag Mixing (PP based Tag Building)
• Boost.Parameter interface for functions and constructors
• Server-Specific Enhancements
∘ Initial Service Framework
∘ Web Development Framework
• ESMTP Support
∘ ESMTP 1.0 Client

Next Steps:
  Document the HTTP Connection concept
  Document the thread pool concept
  Implement space-efficient HTTP request/response types
  Make request/response types PODs
  Support ranges to be made part of the message types
  Boost.Parameter in Templates for Client and Server
---8<--

That said, I would really appreciate it if people can help test the
library on various platforms. I'll be making lots of changes -- expect
some interface breaking changes, especially on the client side,
because the current interface is very limited.

Let me know if you need any specific information, but just people
testing with bjam and/or cmake on their platforms would very much be
appreciated. This is in the meantime until I get to a point where I
can dedicate enough machine power to do the same.

Have a good one and I hope to hear from you soon!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Staying Header-Only?

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

On Tue, Nov 23, 2010 at 4:43 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 22 November 2010 11:31, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> The idea is, when cpp-netlib is used as a header-only library (which
>> is the default case), everything necessary is brought in just like it
>> is implemented now. However, if you use it with
>> BOOST_NETWORK_NO_DEFINITIONS, then the .ipp's aren't included by the
>> .hpp's and all the definitions should be compiled and linked in from
>> an external shared/static library.
>>
>
> Get this wrong and it could be a maintenance nightmare.  Did you look into
> using precompiled headers?  What was your conclusion?
>

I did look at precompiled headers and they're absolutely huge -- 250MB
for the client and/or server. :( Just reading these files on
traditional spinning disks, even mmap'ed just takes too long.

Clang has a different style with precompiled headers, but the
precompiled headers are absolutely huge as well. It may be that all
the template information, though valuable, may be creating too many
AST node representations in compiling.

This might be because of Proto, Fusion, and Spirit, but given that we
are using these libraries internally, I don't see making precompiled
headers a good enough solution to this problem.

Maybe abandoning the header-only approach might actually make the
library better, and allow more developers to be able to contribute.

I'm starting to think this header-only business doesn't really scale well. :(

>>
>> The challenge now is breaking up all the template implementations and
>> making some of the types opaque.
>>
>> Another technique that I would like to re-think is the tag-based
>> metafunction dispatch. I think it's clever, and I definitely think it
>> helps with hiding a lot of the complexity of the library. However, it
>> looks like having a straight-forward policy-based design might even
>> allow more people to develop more policies that can be made part of
>> the library.
>
> A policy-based design would suit the XMPP client much more naturally, IMO.
>  Also, I think tag-based dispatch is overkill for the URI, since the only
> parameter it uses is a string.

Yep. Unless the compilers improve tomorrow and suddenly deal with
templates as though it was a real programming language embedded in C++
compilation, I don't see how this technique can be justified in terms
of the compilation costs.

>>
>> Anyway, I'm getting a hang of writing these long update reports so I
>> hope you bear with me as I go share more of my thoughts with everyone
>> on the list. Let me know if you have any objections, whether you
>> agree, and whether you know of a better way of doing things than what
>> I suggest above.
>>
>
> I agree.  Tag-based dispatching is very powerful but we run up against a
> physical limit which will prevent adoption for anyone but the most
> enthusiastic generic programmer.

Definitely.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Staying Header-Only?

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

Hi Dean,

On 22 November 2010 11:31, Dean Michael Berris <mik...@gm...>wrote:

> Hi Everyone,
>
> A lot of people ask why cpp-netlib is header-only and whether there's
> a way to move some of the library out to externally linked libraries.
> It looks like the compile time is really a big hindrance to some
> people, which is starting to make me question the wisdom of why I'm
> actually fighting to keep cpp-netlib a header-only library.
>
> With that in mind I'm thinking about user-selectable means of
> installing the library. I'm thinking for some people having the
> library only in headers might be an option -- say, if they wanted to
> just distribute a single binary and they were only building a single
> .cpp file and wanted the compiler to be able to optimize everything,
> inline things worth inlining, etc.
>
> So I'm starting with cpp-netlib 0.9 to move some of the
> implementations out into .ipp files, and having struct declarations
> left out in the .hpp files. Now, I'm also looking at making some of
> the templates opaque types, so that some of the function
> implementations can be moved in .cpp files.
>

I think this is a worthwhile task.  I agree that we were being optimistic
when we thought that build times / build size wouldn't matter.


>
> The idea is, when cpp-netlib is used as a header-only library (which
> is the default case), everything necessary is brought in just like it
> is implemented now. However, if you use it with
> BOOST_NETWORK_NO_DEFINITIONS, then the .ipp's aren't included by the
> .hpp's and all the definitions should be compiled and linked in from
> an external shared/static library.
>
>
Get this wrong and it could be a maintenance nightmare.  Did you look into
using precompiled headers?  What was your conclusion?


> The challenge now is breaking up all the template implementations and
> making some of the types opaque.
>
> Another technique that I would like to re-think is the tag-based
> metafunction dispatch. I think it's clever, and I definitely think it
> helps with hiding a lot of the complexity of the library. However, it
> looks like having a straight-forward policy-based design might even
> allow more people to develop more policies that can be made part of
> the library.
>

A policy-based design would suit the XMPP client much more naturally, IMO.
 Also, I think tag-based dispatch is overkill for the URI, since the only
parameter it uses is a string.


> The main push-back I'm getting with the library now is that it's
> taking a lot of resources to build just a simple example. This is a
> non-starter for a lot of people and I am willing to compromise on this
> given that I'm starting to see the larger picture.
>
> Basically, I'm going to move a lot of the static dispatch out from
> metafunctions, and just rely on policies for the client, server, and
> message implementations. The message type can be made opaque (a simple
> struct) which can then just play nicely with the concepts. This would
> remove a lot of the metafunctions that get instantiated all the time
> causing the huge compile time requirements.
>
> As much as I think the tag mechanism we're using is one of a kind and
> is really scalable conceptually, the reality is no current compilers
> can deal with the compile-time costs associated with the technique.
>
> Anyway, I'm getting a hang of writing these long update reports so I
> hope you bear with me as I go share more of my thoughts with everyone
> on the list. Let me know if you have any objections, whether you
> agree, and whether you know of a better way of doing things than what
> I suggest above.
>
>
I agree.  Tag-based dispatching is very powerful but we run up against a
physical limit which will prevent adoption for anyone but the most
enthusiastic generic programmer.

G

[cpp-netlib-devel] Staying Header-Only?

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

Hi Everyone,

A lot of people ask why cpp-netlib is header-only and whether there's
a way to move some of the library out to externally linked libraries.
It looks like the compile time is really a big hindrance to some
people, which is starting to make me question the wisdom of why I'm
actually fighting to keep cpp-netlib a header-only library.

With that in mind I'm thinking about user-selectable means of
installing the library. I'm thinking for some people having the
library only in headers might be an option -- say, if they wanted to
just distribute a single binary and they were only building a single
.cpp file and wanted the compiler to be able to optimize everything,
inline things worth inlining, etc.

So I'm starting with cpp-netlib 0.9 to move some of the
implementations out into .ipp files, and having struct declarations
left out in the .hpp files. Now, I'm also looking at making some of
the templates opaque types, so that some of the function
implementations can be moved in .cpp files.

The idea is, when cpp-netlib is used as a header-only library (which
is the default case), everything necessary is brought in just like it
is implemented now. However, if you use it with
BOOST_NETWORK_NO_DEFINITIONS, then the .ipp's aren't included by the
.hpp's and all the definitions should be compiled and linked in from
an external shared/static library.

The challenge now is breaking up all the template implementations and
making some of the types opaque.

Another technique that I would like to re-think is the tag-based
metafunction dispatch. I think it's clever, and I definitely think it
helps with hiding a lot of the complexity of the library. However, it
looks like having a straight-forward policy-based design might even
allow more people to develop more policies that can be made part of
the library.

The main push-back I'm getting with the library now is that it's
taking a lot of resources to build just a simple example. This is a
non-starter for a lot of people and I am willing to compromise on this
given that I'm starting to see the larger picture.

Basically, I'm going to move a lot of the static dispatch out from
metafunctions, and just rely on policies for the client, server, and
message implementations. The message type can be made opaque (a simple
struct) which can then just play nicely with the concepts. This would
remove a lot of the metafunctions that get instantiated all the time
causing the huge compile time requirements.

As much as I think the tag mechanism we're using is one of a kind and
is really scalable conceptually, the reality is no current compilers
can deal with the compile-time costs associated with the technique.

Anyway, I'm getting a hang of writing these long update reports so I
hope you bear with me as I go share more of my thoughts with everyone
on the list. Let me know if you have any objections, whether you
agree, and whether you know of a better way of doing things than what
I suggest above.

Thanks for reading and I definitely look forward to the feedback.

Have a good one everyone and I hope to hear from you soon!

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] 0.8 is OUT!

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

Hi Everyone!

I just packaged and release 0.8 -- I'm now going to start promoting it
to various channels, and will definitely be on the lookout for
positive feedback.

You can download the latest release at
http://github.com/cpp-netlib/cpp-netlib/downloads -- please try them
out on your platform and let me know through the issues if there are
things that need fixing, and whether a minor release is in order to
address them. I've only been testing with the following compilers and
platforms:

  Linux 64-bit GCC 4.4, 4.5, and Clang 2.8, 2.9-trunk

Thanks everyone for the feedback and the support. Have a good one and
I hope to share more links soon!

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] Starting <unnamed> Company to offer Commercial Support / Custom-Dev for cpp-netlib

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

Hi Everyone,

I've already shared my plans to some friends a few days ago, and now
I'm ready to share a slightly modified, more fleshed-out plan for the
community of cpp-netlib users and developers.

Basically I'm going to bootstrap a company that will be dedicated to
developing and improving cpp-netlib. The business model is similar to
the BoostPro model of commercially supported Boost, but this will be
for cpp-netlib.

I know cpp-netlib is still in its infancy but right now I'm willing to
disclose that I'm going all-in on cpp-netlib. I see a bright future
for cpp-netlib and I would like to make sure that future is
sustainable not only for me but also for the users and developers
contributing to the project.

In the next few weeks there won't be much changes with cpp-netlib as
far as the targets are concerned. It's still being developed to play
nicely with Boost. I'll just be offering commercial support for
cpp-netlib customers, and setting up a commercial forum where those
willing to subscribe to commercial support can get their issues
addressed and the privacy/confidentiality of their queries can be
preserved.

Eventually, once there is enough revenue from the endeavor, I'm
looking to put in some dedicated platform testing resources as well as
a few developers to help out with implementing commercially-sponsored
but still open source features. The idea also includes doing a bounty
system to allow contributing developers to work on specific bounty
items with associated monetary value.

If you're asking what this really means for cpp-netlib, the answer is
really "nothing bad, only good things". I'm setting up the company to
allow enterprises and ISVs who use cpp-netlib to pay for
commercial-grade, dedicated support for their use cases.

Now the company will also be doing products that will be using
cpp-netlib. The products will be shrink-wrapped software that
(unfortunately?) won't be open source, or will be web-based services
that can be availed of through a subscription. This will be the "eat
your own dog food" mentality where it will use cpp-netlib internally
and all enhancements/changes to cpp-netlib will be released into the
open source version.

Don't worry, there will be no "dual-licensed" cpp-neltib or "copyright
assignment" that's going to happen. I believe in the open source model
and that will not change for cpp-netlib. And also, there won't be any
"private forks" that will be owned by the company. Everything to be
developed by the company in relation to cpp-netlib will be pushed to
the official repository.

With that said, I'm already ready to provide commercial support for
cpp-netlib as it stands, I'm just going to formalize the entity as
this year closes.

Thanks very much for reading through this, if you have questions,
concerns, or (ehem) you'd like to get commercial support for
cpp-netlib, send me a private email or reply to the mailing list.

Have a good day and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] New Asynchronous Server Example Up: Static FileServer

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

On Wed, Nov 17, 2010 at 11:23 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
> Dean Michael wrote:
>> I've just pushed to master a new example that highlights the
>> asynchronous server template in 0.8. The example can be found here:
>
> Great news!
>

:-)

>>
>> The example only works on Linux/UNIX where mmap is available, maybe
>> someone can help make this work on Windows too? :)
>>
> Boost iostreams offers platform-independent memory mapping... I've used
> it for an http client sending large files without reading the whole file
> into memory.
>

Interesting. Thanks for the pointer on Boost.Iostreams.

Let me see if I can use Boost.Iostreams for that purpose on this
example, and maybe as the body of request/response objects. Will try
to play around with Boost.Iostreams but it would most probably be
slated for 0.9 if ever I get to supporting it.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] New Asynchronous Server Example Up: Static FileServer

[Nelson, E. - 2 <eri...@ba...>]

Dean Michael wrote:
> I've just pushed to master a new example that highlights the
> asynchronous server template in 0.8. The example can be found here:

Great news!

> 
> The example only works on Linux/UNIX where mmap is available, maybe
> someone can help make this work on Windows too? :)
> 
Boost iostreams offers platform-independent memory mapping... I've used
it for an http client sending large files without reading the whole file
into memory.

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.

[cpp-netlib-devel] New Asynchronous Server Example Up: Static File Server

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

Hi Guys!

I've just pushed to master a new example that highlights the
asynchronous server template in 0.8. The example can be found here:
https://github.com/mikhailberis/cpp-netlib/blob/master/libs/network/example/http/fileserver.cpp
-- I've benchmarked it locally to be able to handle ~3800 RPS on a
dual-core Intel 2GB of RAM serving the README.rst file.

The example only works on Linux/UNIX where mmap is available, maybe
someone can help make this work on Windows too? :)

Have a good one guys and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Can cpp_netlib perform asynchronous concurrent requests?

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

On Sun, Nov 14, 2010 at 2:50 PM, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Nov 13, 2010 at 4:42 PM, qjmann <sou...@gm...> wrote:
>>
>> 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.
>

And with 0.8-beta, you can do this now. :)

I just implemented a wrapper/checker for checking whether a response
object is ready for processing. You can then loop through each
response object with the 'ready' wrapper:

  if (ready(response)) { /* the response is ready here */ }
  else { /* the response is not ready yet */ }

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

I thought it wasn't easy to do, and found myself wanting something
like this too, so I just did it. 0.8 should have it now, as much as
0.8-beta already has it now.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] 2800 RPS locally with Async HTTP Server

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

On Mon, Nov 15, 2010 at 8:22 PM, Steve Obbayi <st...@so...> wrote:
>
> ----- "Dean Michael Berris" <mik...@gm...> wrote:
>
>>
>> Questions about the implementation would be entertained by yours
>> truly
>> so ask away. :)
>>
>> Have a great day guys and I hope this helps! :D
>>
>> --
>
> This is great.
> Did you manage to do any tests on over-the-network requests? If so
> how were the results?
>

Ah, not yet. I will get to those in the next few days and create a
more compelling report on the performance.

Thanks for the reminder. :D

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] 2800 RPS locally with Async HTTP Server

[Steve O. <st...@so...>]

----- "Dean Michael Berris" <mik...@gm...> wrote:

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

This is great.
Did you manage to do any tests on over-the-network requests? If so
how were the results?

-- 
Steve Obbayi

SKYPE: sobbayi
Software Developer

[cpp-netlib-devel] [netlib] 0.8-beta now available!

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

Hi Everyone, advanced apologies for cross-posting.

I've just tagged and uploaded archives of the cpp-netlib 0.8-beta
which features:

  * An asynchronous server template, allowing for server-side
streaming of data, asynchronous writing and reading facilities for
server-side handlers, and a thread pool implementation that's
temporarily using Boost.Asio's io_service for application-specific
asynchronous handlers to run from.
  * A `ready(...)` wrapper to check for whether an asynchronous
client's response is ready.

The documentation has also been updated to feature a brand-new
reference manual detailing the implementation, caveats, and public API
of the HTTP client and server templates.

You can go ahead and download the 0.8-beta and report issues you find
either directly to me or through the mailing lists (Boost.User,
Boost.Devel, and the cpp-netlib developers mailing lists).

The target release for 0.8 will be this Friday, November 19, 2010.

As usual, you can download the 0.8-beta package from GitHub at:

  https://github.com/cpp-netlib/cpp-netlib/downloads

You can also check out the documentation for 0.8-beta at:

  http://cpp-netlib.github.com/0.8-beta

Thanks everyone and I look forward to most appreciated feedback!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Merge to master

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

Hi Steve!

On Mon, Nov 15, 2010 at 6:11 PM, Steve Hartwell
<ste...@gm...> wrote:
> Dean Michael Berris <mikhailberis@...> writes:
> ...
>> Is anybody able to check out the documentation and see if there are
>> any glaring issues that need to be addressed?
>
> The documentation is coming along well.  I'd like to see a little bit on
> the client::request and client::response public API, particularly their
> use on the async variants.
>

Thanks! I'll write up the sections for reference on the Client API
either later today or early tomorrow.

I've just finished the documentation of the Server API. I'm looking to
do something similar for the Client API in discussing the actual
wrappers, directives, and modifiers that are supported by the
client::request and client::response types and instances of those.

>> Feedback would be greatly appreciated.
>
> It's a very impressive library design, and more so given its
> comprehensive use of Boost.  I particularly admire your diligence in
> constructing the Concept checks.
>

Thank you. :)

> Having read through recent discussions on Request and Response body
> representations, I have to agree with others that a string type (or any
> container which assumes contiguous storage) is unsuitable for production
> use.  Of course, having body representations /constructible/ from
> strings is desirable for the ease of use you are advocating, similar in
> convenience to stringstream.
>
> You may have already considered using the Boost.Iostreams Source concept
> for the client::request body, and the Sink concept for the
> client::response body.  I think that chunking, transfer-encoding,
> multipart/form, and MIME layers would be much more manageable with the
> Boost.Iostream Filter concept, too.
>

Yeah, the request/response body representation is a little testy from
the way it's set up right now and the way others want to use it. I was
thinking that for simple web application calls, strings would be
enough -- and I haven't considered streaming files through the client
interface. :D

I haven't considered Boost.Iostreams before and now that you mention
it, it's a good idea to model the concepts or even introduce it as a
dependency of the library. My only worry with this is the added
dependency, which I'm already thinking about cutting down (especially
because some dependencies require externally built libraries).

I am considering a less "greedy" implementation that allows for the
body to be consumed through an Iostream interface wrapping the
Boost.Asio socket in an object that allows for stream-like access.
Maybe playing well with the Boost.Iostreams Source concept would be a
good thing too. This is for the response object.

For the request object, I might consider just taking in a single-pass
range that can be copied around lightly. I'll need more experience
with Boost.Iostream to see if I can require a request's body to be a
"Source" to be more generic about it.

I'll look into that as soon as I release 0.8 with the asynchronous
server implementation. My focus this past few weeks has been the
server side, and I can shift back to the client side in the next
release.

>> Thanks and have a good day guys.
>
> Thanks and best wishes to you.
>

Thanks for sharing your thoughts Steve! They're definitely most appreciated.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Merge to master

[Steve H. <ste...@gm...>]

Dean Michael Berris <mikhailberis@...> writes:
...
> Is anybody able to check out the documentation and see if there are
> any glaring issues that need to be addressed?

The documentation is coming along well.  I'd like to see a little bit on
the client::request and client::response public API, particularly their
use on the async variants.

> Feedback would be greatly appreciated.

It's a very impressive library design, and more so given its
comprehensive use of Boost.  I particularly admire your diligence in
constructing the Concept checks.

Having read through recent discussions on Request and Response body
representations, I have to agree with others that a string type (or any
container which assumes contiguous storage) is unsuitable for production
use.  Of course, having body representations /constructible/ from
strings is desirable for the ease of use you are advocating, similar in
convenience to stringstream.

You may have already considered using the Boost.Iostreams Source concept
for the client::request body, and the Sink concept for the
client::response body.  I think that chunking, transfer-encoding,
multipart/form, and MIME layers would be much more manageable with the
Boost.Iostream Filter concept, too.

> Thanks and have a good day guys.

Thanks and best wishes to you.

/Steve Hartwell
YouSendIt.com

[cpp-netlib-devel] Merge to master

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

Hi Everyone,

I would just like to give a heads up that I will soon be merging the
implementation to HEAD. I'm just finishing up the documentation
(specifically the reference manual) and would be throwing up a link
later in my day.

Is anybody able to check out the documentation and see if there are
any glaring issues that need to be addressed?

Feedback would be greatly appreciated.

Thanks and have a good day guys.

-- 
Dean Michael Berris
deanberris.com