cpp-netlib-devel Mailing List for C++ Network Library (Page 49)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Ping Mike?

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

Hi Mike,

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Monday, April 21, 2008 11:43 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> I like it!  Makes me wonder though, if maybe we should just 
> make all these part of the http "message traits," and do away 
> with the "parser traits" concept altogether?
>

Sounds good to me. ;) Actually, it's just a simple change in the header
includes. I'll save that for later though. :D

Do you have a good estimate Mike on when we can see more libpion parser
code (and tests) getting into the library? I'm itching to get started on
this just so you know... ;)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Divye Kapoor
> Sent: Monday, April 21, 2008 9:52 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> Hi,
> 
> 
> On Mon, Apr 21, 2008 at 2:06 PM, Dean Michael C. Berris 
> <dmb...@fr...> wrote:
> 
> 
> 	I like this rate that we're proceeding. I'll try 
> writing more tests to
> 	satisfy some of Divye's curiousity -- or if you're 
> already trying your
> 	hand at those Divye, please let me know so we can coordinate
> 	accordingly.
> 	
> 
>  
>   Exams are fast approaching and regular quizzes are keeping 
> me busy. I'm currently looking only at what's being checked 
> in and viewing it as a potential user :-) Don't mind my 
> passiveness for now. I'll get down to writing black box tests 
> for verification of the HTTP protocol specifications only 
> after my exams (thats after the 13th of May. But I'll 
> definitely be keeping track of progress and put in a line of 
> code or two. Thanks to all this, I'm learning about Boost Tests. 
> 

Take your time, it's nice to know that you're still interested. :)

> A note: The tests that were recently checked in do not time 
> out even after 5 minutes on a linux system. I'll try those 
> tests on Windows and post any differences.
> 

Yup. And I'll have to move away from Boost.Asio's iostream interface --
unless it actually implements a timeout on the stream that I don't know
about yet.

This is actually high time for the libPion HTTP client implementation to
move into the http::client implementation. I think if we can actually
unit-test parts of the parser(s), and then move the implementation into
the HTTP client we already have, we should be able to move forward at a
better pace -- with error condition checking, etc.

As for that, I'll have to wait for Mike's moving the files into the
repository to get me started on this. :)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Monday, April 21, 2008 11:39 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Bjam woes
> 
> I tried setting those two env variables on my second test.  I 
> discovered that there are two more subtle requirements to 
> this approach:
> 
> a) your "BOOST_ROOT" directory needs to be writable
> b) the code in your "BOOST_ROOT" directory needs to be built
> 
> although I suspect b) might not be necessary if the directory 
> is writable
> 

Yes, if it's already writable, the required libraries will be built when
running bjam in the test directory. :)

> I think that having simple ./configure + make to wrap the 
> bjam stuff would make things much easier to use, sort of like 
> what is available for the main boost distribution..  In 
> particular, it could find where you bjam is located, and 
> allow you to set the location of your
> (source) BOOST_ROOT, or alternatively to specify an "installed"  
> location of the boost libraries.  If the latter, it would 
> just write a new Jamroot file that takes an approach similar 
> to Andreas (specify the include locations and libraries we 
> need to link with explicitly).
> 

This is fine, however, the main appeal of using just Bjam is that it
works in Windows without requiring the autotools to be there. For
example, I develop both on Windows and Linux -- this allows me to use
the same build tool and process on either platform.

And no, installing cygwin is not an option for me. ;)

> I realize this would all be redundant after it's (hopefully) 
> included in the Boost distro, but in the meantime I think it 
> would make things much easier to use. I can take a stab at 
> this, since I've grown quite familiar with autotools over the 
> past year..
> 

Agreed, but it would only be useful for people who use Linux or UNIX
like systems that have make available. :)

> Regarding the unit test libraries, these seem to be built and 
> included in the distro by default on most platforms anyway.  
> Plus, since cpp- netlib is taking a headers-only approach, 
> the unit tests are the only thing someone can build.  So it 
> seems like a reasonable requirement that you can't "build" 
> cpp-netlib without having the unit test library to link with.
> 

Yes. And actually, we can even package Boost.Test and all the other
Boost Libraries along with the cpp-netlib if we really want to go and
make it self-contained. ;)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

I like it!  Makes me wonder though, if maybe we should just make all  
these part of the http "message traits," and do away with the "parser  
traits" concept altogether?

-Mike

On Apr 21, 2008, at 1:36 AM, Dean Michael C. Berris wrote:

> Okay, so just now I chopped up parser_traits into the following files:
> 	
> network/protocol/http/traits/impl/cookie_name.ipp
> network/protocol/http/traits/impl/cookie_value.ipp
> network/protocol/http/traits/impl/header_name.ipp
> network/protocol/http/traits/impl/header_value.ipp
> network/protocol/http/traits/impl/method.ipp
> network/protocol/http/traits/impl/post_content.ipp
> network/protocol/http/traits/impl/query_name.ipp
> network/protocol/http/traits/impl/query_string.ipp
> network/protocol/http/traits/impl/query_value.ipp
> network/protocol/http/traits/impl/resource.ipp
> network/protocol/http/traits/impl/status_message.ipp
> network/protocol/http/traits/parser_traits.hpp
>
> In this approach, we then use the tag dispatch to get the appropriate
> typedef for the MAX nested static value:
>
> 	http::cookie_name<http::message_tag>::MAX; // 1024u
>
> Mike, please let me know when you think we can start changing the  
> parser
> implementation(s) to use the newer traits mechanisms.
>
> I like this rate that we're proceeding. I'll try writing more tests to
> satisfy some of Divye's curiousity -- or if you're already trying your
> hand at those Divye, please let me know so we can coordinate
> accordingly.
>
> Have a good day guys!
>
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
> <dmb...@fr...>
> +639287291459
>
>
>> -----Original Message-----
>> From: cpp...@li...
>> [mailto:cpp...@li...] On
>> Behalf Of Dean Michael C. Berris
>> Sent: Monday, April 21, 2008 2:15 PM
>> To: C++ Networking Library Developers Mailing List
>> Subject: Re: [cpp-netlib-devel] Review of http::message
>>
>>> -----Original Message-----
>>> From: cpp...@li...
>>> [mailto:cpp...@li...] On
>> Behalf Of
>>> Michael Dickey
>>> Sent: Monday, April 21, 2008 4:20 AM
>>> To: C++ Networking Library Developers Mailing List
>>> Subject: Re: [cpp-netlib-devel] Review of http::message
>>>
>>> The new approach sounds (and now, looks) good to me.
>>>
>>
>> Nice. That's good to know Mike. :)
>>
>>> Although I noticed that parser_traits.hpp appears to be
>> just a copy of
>>> the traits.hpp file (the parser constants seem to have been lost
>>> somewhere in the update).  Whether these are called
>> 'parser_traits',
>>> 'parser_consts' or anything else is fine with me =)
>>>
>>
>> Yeah, I haven't gotten to chopping that file up just yet. I'm
>> still mulling around the name(s), but I think I'll just go
>> first with parser_consts or a more fine-grained approach at
>> decomposing the various constants contained in parser_traits.
>> I'll let you know when I get something in soon. :)
>>
>> Thanks Mike!
>>
>> --
>> Dean Michael Berris
>> Software Engineer, Friendster, Inc.
>> <dmb...@fr...>
>> +639287291459
>>
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.net email is sponsored by the 2008 JavaOne(SM)
>> Conference Don't miss this year's exciting event. There's
>> still time to save $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
>> .sun.com/javaone
>> _______________________________________________
>> Cpp-netlib-devel mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

I tried setting those two env variables on my second test.  I  
discovered that there are two more subtle requirements to this approach:

a) your "BOOST_ROOT" directory needs to be writable
b) the code in your "BOOST_ROOT" directory needs to be built

although I suspect b) might not be necessary if the directory is  
writable

I think that having simple ./configure + make to wrap the bjam stuff  
would make things much easier to use, sort of like what is available  
for the main boost distribution..  In particular, it could find where  
you bjam is located, and allow you to set the location of your  
(source) BOOST_ROOT, or alternatively to specify an "installed"  
location of the boost libraries.  If the latter, it would just write a  
new Jamroot file that takes an approach similar to Andreas (specify  
the include locations and libraries we need to link with explicitly).

I realize this would all be redundant after it's (hopefully) included  
in the Boost distro, but in the meantime I think it would make things  
much easier to use. I can take a stab at this, since I've grown quite  
familiar with autotools over the past year..

Regarding the unit test libraries, these seem to be built and included  
in the distro by default on most platforms anyway.  Plus, since cpp- 
netlib is taking a headers-only approach, the unit tests are the only  
thing someone can build.  So it seems like a reasonable requirement  
that you can't "build" cpp-netlib without having the unit test library  
to link with.

Take care,
-Mike

On Apr 20, 2008, at 11:24 PM, Dean Michael C. Berris wrote:

> Hi Mike!
>
> So here are the environment variables you need to set up:
>
> BOOST_ROOT=/path/to/boost/distribution/root
> BOOST_BUILD_PATH=/path/to/boost/build/root
>
> So in your setup, you might have Boost.Build in /usr/share/boost_build
> and have your Boost distribution root at /usr/local/boost_1_35_0. My
> suggestion is to use the Boost.Build inside the
> $(BOOST_ROOT)/tools/build/v2 directory.
>
> So you'd do something like:
>
> export BOOST_ROOT=/usr/local/boost_1_35_0
> export BOOST_BUILD_PATH=$(BOOST_ROOT)/tools/build/v2
>
> What you need to build the tests inside libs/cpp-netlib/test/ -- in  
> that
> directory, run 'bjam'.
>
> That should get you working just fine. If you still encounter  
> problems,
> then just let me know so that I look into it myself. :)
>
> PS. We ought to have a ./configure script which should find where the
> BOOST_ROOT is if it's not set in the environment path. However, I  
> think
> that's more of an afterthough given that we're only just a handful of
> developers working on this project.
>
> PPS. And the reason why we need the whole Boost distribution is  
> because
> we require the Boost.Test libs to be built and linked from source. We
> *can* change the Jamfile inside the test directory to not require
> "<source>/boost//unit_test_framework" but that would require the
> Boost.Test libs be installed in the system -- which I don't really  
> want
> to require. So the safest bet for now is to have the whole Boost
> distribution available from somewhere. ;)
>
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
> <dmb...@fr...>
> +639287291459
>
>
>> -----Original Message-----
>> From: cpp...@li...
>> [mailto:cpp...@li...] On
>> Behalf Of Michael Dickey
>> Sent: Monday, April 21, 2008 4:44 AM
>> To: C++ Networking Library Developers Mailing List
>> Subject: [cpp-netlib-devel] Bjam woes
>>
>> Unfortunately, I've been having a very hard time trying to get bjam/
>> Boost.Build setup and working properly..
>>
>> First, I find the distinction between "bjam" and "Boost.Build" to be
>> very confusing (two separate projects, separate distributions, the
>> names are used interchangeably, and you cannot seem to use
>> one without
>> the other), and the documentation currently available I think
>> is quite
>> unclear..  I read through the tutorial, installed the bjam
>> executable
>> in my path, and installed the boost-build distribution
>> package in /usr/
>> share/boost-build.  I'm able to build the projects in the examples
>> directory, but running "bjam" in a cpp-netlib directory gives me:
>>
>> Jamroot:11: in modules.load
>> *** argument error
>> * rule use-project ( id : where )
>> * called with: ( /boost :  )
>> * missing argument where
>> /usr/share/boost-build/build/project.jam:956:see definition of rule
>> 'use-project' being called
>> /usr/share/boost-build/build/project.jam:312: in load-jamfile
>> /usr/share/boost-build/build/project.jam:68: in load
>> /usr/share/boost-build/build/project.jam:170: in project.find
>> /usr/share/boost-build/build-system.jam:248: in load
>> /usr/share/boost-build/kernel/modules.jam:261: in import
>> /usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build
>> /usr/share/boost-build/boost-build.jam:1: in module scope
>>
>> My guess is that this means bjam &| Boost.Build cannot find
>> the boost
>> libraries?  Interestingly enough, I can find no place in the
>> tutorial
>> or elsewhere in the documentation where it talks about setting this
>> up, only the setup for your compiler.
>>
>> I found some talk about having to set a BOOST_ROOT variable via
>> google, so I tried pointing this to a directory containing the boost
>> 1.35.0 distro.  Unfortunately, this just gives me a whole
>> other set of
>> errors.  Plus, it would make little sense to me if having a source
>> distribution is required..
>>
>> mdickey@terra cpp-netlib]$ export
>> BOOST_ROOT=/share/home/mdickey/code/
>> boost_1_35_0
>> [mdickey@terra cpp-netlib]$ bjam
>> warning: Graph library does not contain optional GraphML reader.
>> note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH
>> to the
>> note: directories containing the Expat headers and libraries,
>> respectively.
>> warning: skipping optional Message Passing Interface (MPI) library.
>> note: to enable MPI support, add "using mpi ;" to user-config.jam.
>> note: to suppress this message, pass "--without-mpi" to bjam.
>> note: otherwise, you can safely ignore this message.
>> Building Boost.Regex with the optional Unicode/ICU support disabled.
>> Please refer to the Boost.Regex documentation for more information
>> (don't panic: this is a strictly optional feature).
>> /usr/share/boost-build/build/virtual-target.jam:423: in _adjust-name
>> from module object(file-target)@558
>> ...
>>
>> Oh my!  I know the autotools stuff can be a bit of a dinosaur/pain,
>> but the good ole "./configure; make" seems a lot more
>> friendly to me! =)
>>
>> There must be some simple way to say "Boost is installed in /usr/
>> local/".  I thought about re-writing the Jamroot file to set
>> everything up manually as a project, but I'm sure it can't be that
>> difficult...  There must be something silly and trivial that I am
>> missing here..
>>
>> Thanks for any help,
>> -Mike
>>
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to
>> save $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
>> .sun.com/javaone
>> _______________________________________________
>> Cpp-netlib-devel mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Hi,

On Mon, Apr 21, 2008 at 2:06 PM, Dean Michael C. Berris <
dmb...@fr...> wrote:

> I like this rate that we're proceeding. I'll try writing more tests to
> satisfy some of Divye's curiousity -- or if you're already trying your
> hand at those Divye, please let me know so we can coordinate
> accordingly.
>

  Exams are fast approaching and regular quizzes are keeping me busy. I'm
currently looking only at what's being checked in and viewing it as a
potential user :-) Don't mind my passiveness for now. I'll get down to
writing black box tests for verification of the HTTP protocol specifications
only after my exams (thats after the 13th of May. But I'll definitely be
keeping track of progress and put in a line of code or two. Thanks to all
this, I'm learning about Boost Tests.

A note: The tests that were recently checked in do not time out even after 5
minutes on a linux system. I'll try those tests on Windows and post any
differences.

Regards,
Divye

-- 
Whether the chicken crossed the road or the road moved beneath the chicken
depends upon your frame of reference.
My official web site:
http://www.iitr.ernet.in/studenthomepages/homepages/061305

Okay, so just now I chopped up parser_traits into the following files:

network/protocol/http/traits/impl/cookie_name.ipp
network/protocol/http/traits/impl/cookie_value.ipp
network/protocol/http/traits/impl/header_name.ipp
network/protocol/http/traits/impl/header_value.ipp
network/protocol/http/traits/impl/method.ipp
network/protocol/http/traits/impl/post_content.ipp
network/protocol/http/traits/impl/query_name.ipp
network/protocol/http/traits/impl/query_string.ipp
network/protocol/http/traits/impl/query_value.ipp
network/protocol/http/traits/impl/resource.ipp
network/protocol/http/traits/impl/status_message.ipp
network/protocol/http/traits/parser_traits.hpp

In this approach, we then use the tag dispatch to get the appropriate
typedef for the MAX nested static value:

	http::cookie_name<http::message_tag>::MAX; // 1024u

Mike, please let me know when you think we can start changing the parser
implementation(s) to use the newer traits mechanisms.

I like this rate that we're proceeding. I'll try writing more tests to
satisfy some of Divye's curiousity -- or if you're already trying your
hand at those Divye, please let me know so we can coordinate
accordingly.

Have a good day guys!

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Dean Michael C. Berris
> Sent: Monday, April 21, 2008 2:15 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> > -----Original Message-----
> > From: cpp...@li...
> > [mailto:cpp...@li...] On 
> Behalf Of 
> > Michael Dickey
> > Sent: Monday, April 21, 2008 4:20 AM
> > To: C++ Networking Library Developers Mailing List
> > Subject: Re: [cpp-netlib-devel] Review of http::message
> > 
> > The new approach sounds (and now, looks) good to me.
> >
> 
> Nice. That's good to know Mike. :)
>  
> > Although I noticed that parser_traits.hpp appears to be 
> just a copy of 
> > the traits.hpp file (the parser constants seem to have been lost 
> > somewhere in the update).  Whether these are called 
> 'parser_traits', 
> > 'parser_consts' or anything else is fine with me =)
> > 
> 
> Yeah, I haven't gotten to chopping that file up just yet. I'm 
> still mulling around the name(s), but I think I'll just go 
> first with parser_consts or a more fine-grained approach at 
> decomposing the various constants contained in parser_traits. 
> I'll let you know when I get something in soon. :)
> 
> Thanks Mike!
> 
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
> <dmb...@fr...>
> +639287291459
>  
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) 
> Conference Don't miss this year's exciting event. There's 
> still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
> .sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
> 

Hi Mike!

So here are the environment variables you need to set up:

BOOST_ROOT=/path/to/boost/distribution/root
BOOST_BUILD_PATH=/path/to/boost/build/root

So in your setup, you might have Boost.Build in /usr/share/boost_build
and have your Boost distribution root at /usr/local/boost_1_35_0. My
suggestion is to use the Boost.Build inside the
$(BOOST_ROOT)/tools/build/v2 directory.

So you'd do something like:

export BOOST_ROOT=/usr/local/boost_1_35_0
export BOOST_BUILD_PATH=$(BOOST_ROOT)/tools/build/v2

What you need to build the tests inside libs/cpp-netlib/test/ -- in that
directory, run 'bjam'.

That should get you working just fine. If you still encounter problems,
then just let me know so that I look into it myself. :)

PS. We ought to have a ./configure script which should find where the
BOOST_ROOT is if it's not set in the environment path. However, I think
that's more of an afterthough given that we're only just a handful of
developers working on this project.

PPS. And the reason why we need the whole Boost distribution is because
we require the Boost.Test libs to be built and linked from source. We
*can* change the Jamfile inside the test directory to not require
"<source>/boost//unit_test_framework" but that would require the
Boost.Test libs be installed in the system -- which I don't really want
to require. So the safest bet for now is to have the whole Boost
distribution available from somewhere. ;)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Monday, April 21, 2008 4:44 AM
> To: C++ Networking Library Developers Mailing List
> Subject: [cpp-netlib-devel] Bjam woes
> 
> Unfortunately, I've been having a very hard time trying to get bjam/ 
> Boost.Build setup and working properly..
> 
> First, I find the distinction between "bjam" and "Boost.Build" to be  
> very confusing (two separate projects, separate distributions, the  
> names are used interchangeably, and you cannot seem to use 
> one without  
> the other), and the documentation currently available I think 
> is quite  
> unclear..  I read through the tutorial, installed the bjam 
> executable  
> in my path, and installed the boost-build distribution 
> package in /usr/ 
> share/boost-build.  I'm able to build the projects in the examples  
> directory, but running "bjam" in a cpp-netlib directory gives me:
> 
> Jamroot:11: in modules.load
> *** argument error
> * rule use-project ( id : where )
> * called with: ( /boost :  )
> * missing argument where
> /usr/share/boost-build/build/project.jam:956:see definition of rule  
> 'use-project' being called
> /usr/share/boost-build/build/project.jam:312: in load-jamfile
> /usr/share/boost-build/build/project.jam:68: in load
> /usr/share/boost-build/build/project.jam:170: in project.find
> /usr/share/boost-build/build-system.jam:248: in load
> /usr/share/boost-build/kernel/modules.jam:261: in import
> /usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build
> /usr/share/boost-build/boost-build.jam:1: in module scope
> 
> My guess is that this means bjam &| Boost.Build cannot find 
> the boost  
> libraries?  Interestingly enough, I can find no place in the 
> tutorial  
> or elsewhere in the documentation where it talks about setting this  
> up, only the setup for your compiler.
> 
> I found some talk about having to set a BOOST_ROOT variable via  
> google, so I tried pointing this to a directory containing the boost  
> 1.35.0 distro.  Unfortunately, this just gives me a whole 
> other set of  
> errors.  Plus, it would make little sense to me if having a source  
> distribution is required..
> 
> mdickey@terra cpp-netlib]$ export 
> BOOST_ROOT=/share/home/mdickey/code/ 
> boost_1_35_0
> [mdickey@terra cpp-netlib]$ bjam
> warning: Graph library does not contain optional GraphML reader.
> note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH  
> to the
> note: directories containing the Expat headers and libraries,  
> respectively.
> warning: skipping optional Message Passing Interface (MPI) library.
> note: to enable MPI support, add "using mpi ;" to user-config.jam.
> note: to suppress this message, pass "--without-mpi" to bjam.
> note: otherwise, you can safely ignore this message.
> Building Boost.Regex with the optional Unicode/ICU support disabled.
> Please refer to the Boost.Regex documentation for more information
> (don't panic: this is a strictly optional feature).
> /usr/share/boost-build/build/virtual-target.jam:423: in _adjust-name  
> from module object(file-target)@558
> ...
> 
> Oh my!  I know the autotools stuff can be a bit of a dinosaur/pain,  
> but the good ole "./configure; make" seems a lot more 
> friendly to me! =)
> 
> There must be some simple way to say "Boost is installed in /usr/ 
> local/".  I thought about re-writing the Jamroot file to set  
> everything up manually as a project, but I'm sure it can't be that  
> difficult...  There must be something silly and trivial that I am  
> missing here..
> 
> Thanks for any help,
> -Mike
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to 
> save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
> .sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
> 

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Monday, April 21, 2008 4:20 AM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> The new approach sounds (and now, looks) good to me.
>

Nice. That's good to know Mike. :)

> Although I noticed that parser_traits.hpp appears to be just 
> a copy of the traits.hpp file (the parser constants seem to 
> have been lost somewhere in the update).  Whether these are 
> called 'parser_traits', 'parser_consts' or anything else is 
> fine with me =)
> 

Yeah, I haven't gotten to chopping that file up just yet. I'm still
mulling around the name(s), but I think I'll just go first with
parser_consts or a more fine-grained approach at decomposing the various
constants contained in parser_traits. I'll let you know when I get
something in soon. :)

Thanks Mike!

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

Hi Divye,

These are great observations, thanks for taking the time. Let me try and
address your questions inline below.

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Divye Kapoor
> Sent: Sunday, April 20, 2008 1:53 AM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Implemented Rudimentary Unit 
> Test inbranchhttp_integration
> 
> Hi,
> I was just going through the test code and I found 2 
> difficulties:- 1. The http 1.0 implementation tests don't 
> seem to fail if they are run with no network connection (or 
> didn't I wait long enough for them to time out?) 

I actually haven't tried this myself -- and admittedly, had not been
thinking about this when my focus was getting tests in to make sure that
the implementation compiles first. However, you should be getting a
timeout error but depending on your OS, the amount of time it takes may
not simply be 30 seconds -- although I think in Linux this is the OS
default.

> 2. There 
> doesn't seem to be any timeout or connection status feedback 
> available with the client object. For example, how does a 
> client come to know that a connection seems stalled and needs 
> a restart (for example, an intelligent download agent?). 

You're right -- this information should be put into the 'get' or 'post'
methods, most probably refactored into its own (private) function inside
the client. This can be a simple Asio Timeout handler using an approach
given by Chris Kohlhoff in one of our conversations on the Boost C++
developers list. I can implement the changes later.

> Where does this kind of info fit in the basic_message 
> hierarchy?  (I didn't find any appropriate functions or tests 
> for this kind of situation)
> 

It actually doesn't it in the basic_message hierarchy because timeouts
are not part of the message abstraction. This rather is a protocol
client specific thing and should be handled at that layer.

> Have I looked at the right places for these things or have I 
> missed them completely?
> 

You've looked at the tests so I'd say you've been looking at the right
place(s). :)

Thanks Divye!

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

In your Jamfile.v2 you should reference $(BOOST_ROOT)

I'll copy/paste my Jamfile.v2 that I use for my little DNS library here.

------

import os ;
local BOOST_ROOT = [ os.environ BOOST_ROOT ] ;

if [ os.name ] = SOLARIS
{
lib socket ;
lib nsl ;
}
else if [ os.name ] = NT
{
lib ws2_32 ;
lib mswsock ;
}

project : requirements
<include>../../../
<include>$(BOOST_ROOT)
<define>BOOST_ALL_NO_LIB=1
<library>$(BOOST_ROOT)/libs/system/build//boost_system
<library>$(BOOST_ROOT)/libs/thread/build//boost_thread
<threading>multi
<link>static
<os>SOLARIS:<library>socket
<os>SOLARIS:<library>nsl
<os>NT,<toolset>gcc:<library>ws2_32
<os>NT,<toolset>gcc:<library>mswsock
;

exe dns_simple : dns_simple.cpp dns_util.cpp ;

----

This Jamfile lives in a directory 3 levels away from the .hpp files that
I need.

You'll also need the infamous project-root.jam at the base of your
directory that you are writing in.

Michael Dickey wrote:

> Unfortunately, I've been having a very hard time trying to get bjam/ 
> Boost.Build setup and working properly..
>
> First, I find the distinction between "bjam" and "Boost.Build" to be  
> very confusing (two separate projects, separate distributions, the  
> names are used interchangeably, and you cannot seem to use one without  
> the other), and the documentation currently available I think is quite  
> unclear..  I read through the tutorial, installed the bjam executable  
> in my path, and installed the boost-build distribution package in /usr/ 
> share/boost-build.  I'm able to build the projects in the examples  
> directory, but running "bjam" in a cpp-netlib directory gives me:
>
> Jamroot:11: in modules.load
> *** argument error
> * rule use-project ( id : where )
> * called with: ( /boost :  )
> * missing argument where
> /usr/share/boost-build/build/project.jam:956:see definition of rule  
> 'use-project' being called
> /usr/share/boost-build/build/project.jam:312: in load-jamfile
> /usr/share/boost-build/build/project.jam:68: in load
> /usr/share/boost-build/build/project.jam:170: in project.find
> /usr/share/boost-build/build-system.jam:248: in load
> /usr/share/boost-build/kernel/modules.jam:261: in import
> /usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build
> /usr/share/boost-build/boost-build.jam:1: in module scope
>
> My guess is that this means bjam &| Boost.Build cannot find the boost  
> libraries?  Interestingly enough, I can find no place in the tutorial  
> or elsewhere in the documentation where it talks about setting this  
> up, only the setup for your compiler.
>
> I found some talk about having to set a BOOST_ROOT variable via  
> google, so I tried pointing this to a directory containing the boost  
> 1.35.0 distro.  Unfortunately, this just gives me a whole other set of  
> errors.  Plus, it would make little sense to me if having a source  
> distribution is required..
>
> mdickey@terra cpp-netlib]$ export BOOST_ROOT=/share/home/mdickey/code/ 
> boost_1_35_0
> [mdickey@terra cpp-netlib]$ bjam
> warning: Graph library does not contain optional GraphML reader.
> note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH  
> to the
> note: directories containing the Expat headers and libraries,  
> respectively.
> warning: skipping optional Message Passing Interface (MPI) library.
> note: to enable MPI support, add "using mpi ;" to user-config.jam.
> note: to suppress this message, pass "--without-mpi" to bjam.
> note: otherwise, you can safely ignore this message.
> Building Boost.Regex with the optional Unicode/ICU support disabled.
> Please refer to the Boost.Regex documentation for more information
> (don't panic: this is a strictly optional feature).
> /usr/share/boost-build/build/virtual-target.jam:423: in _adjust-name  
> from module object(file-target)@558
> ...
>
> Oh my!  I know the autotools stuff can be a bit of a dinosaur/pain,  
> but the good ole "./configure; make" seems a lot more friendly to me! =)
>
> There must be some simple way to say "Boost is installed in /usr/ 
> local/".  I thought about re-writing the Jamroot file to set  
> everything up manually as a project, but I'm sure it can't be that  
> difficult...  There must be something silly and trivial that I am  
> missing here..
>
> Thanks for any help,
> -Mike
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

Unfortunately, I've been having a very hard time trying to get bjam/ 
Boost.Build setup and working properly..

First, I find the distinction between "bjam" and "Boost.Build" to be  
very confusing (two separate projects, separate distributions, the  
names are used interchangeably, and you cannot seem to use one without  
the other), and the documentation currently available I think is quite  
unclear..  I read through the tutorial, installed the bjam executable  
in my path, and installed the boost-build distribution package in /usr/ 
share/boost-build.  I'm able to build the projects in the examples  
directory, but running "bjam" in a cpp-netlib directory gives me:

Jamroot:11: in modules.load
*** argument error
* rule use-project ( id : where )
* called with: ( /boost :  )
* missing argument where
/usr/share/boost-build/build/project.jam:956:see definition of rule  
'use-project' being called
/usr/share/boost-build/build/project.jam:312: in load-jamfile
/usr/share/boost-build/build/project.jam:68: in load
/usr/share/boost-build/build/project.jam:170: in project.find
/usr/share/boost-build/build-system.jam:248: in load
/usr/share/boost-build/kernel/modules.jam:261: in import
/usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build
/usr/share/boost-build/boost-build.jam:1: in module scope

My guess is that this means bjam &| Boost.Build cannot find the boost  
libraries?  Interestingly enough, I can find no place in the tutorial  
or elsewhere in the documentation where it talks about setting this  
up, only the setup for your compiler.

I found some talk about having to set a BOOST_ROOT variable via  
google, so I tried pointing this to a directory containing the boost  
1.35.0 distro.  Unfortunately, this just gives me a whole other set of  
errors.  Plus, it would make little sense to me if having a source  
distribution is required..

mdickey@terra cpp-netlib]$ export BOOST_ROOT=/share/home/mdickey/code/ 
boost_1_35_0
[mdickey@terra cpp-netlib]$ bjam
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH  
to the
note: directories containing the Expat headers and libraries,  
respectively.
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
Building Boost.Regex with the optional Unicode/ICU support disabled.
Please refer to the Boost.Regex documentation for more information
(don't panic: this is a strictly optional feature).
/usr/share/boost-build/build/virtual-target.jam:423: in _adjust-name  
from module object(file-target)@558
...

Oh my!  I know the autotools stuff can be a bit of a dinosaur/pain,  
but the good ole "./configure; make" seems a lot more friendly to me! =)

There must be some simple way to say "Boost is installed in /usr/ 
local/".  I thought about re-writing the Jamroot file to set  
everything up manually as a project, but I'm sure it can't be that  
difficult...  There must be something silly and trivial that I am  
missing here..

Thanks for any help,
-Mike

The new approach sounds (and now, looks) good to me.

Although I noticed that parser_traits.hpp appears to be just a copy of  
the traits.hpp file (the parser constants seem to have been lost  
somewhere in the update).  Whether these are called 'parser_traits',  
'parser_consts' or anything else is fine with me =)

-Mike

On Apr 15, 2008, at 5:18 AM, Dean Michael C. Berris wrote:

>> -----Original Message-----
>> From: cpp...@li...
>> [mailto:cpp...@li...] On
>> Behalf Of Glyn Matthews
>> Sent: Tuesday, April 15, 2008 8:06 PM
>> To: C++ Networking Library Developers Mailing List
>> Subject: Re: [cpp-netlib-devel] Review of http::message
>>
>>
>> Would it be possible to do something like the following:
>> namespace http {
>> namespace tags {
>> struct message_tag {};
>> struct message_tag_w {};
>> }
>> }
>>
>> namespace http {
>> namespace traits {
>> template <
>>    typename Tag
>>>
>> struct delimiters;
>>
>>
>> template <>
>> struct delimiters<tags::message_tag> {
>>    static char const *crlf() {
>>        static const char *const crlf = "\x0D\x0A";
>>        return crlf;
>>    }
>> };
>>
>>
>> template <>
>> struct delimiters<tags::message_tag_w> {
>>    static wchar_t const *crlf() {
>>        static const wchar_t *const crlf =  L"\x0D\x0A";
>>        return crlf;
>>    }
>> };
>> }
>> }
>>
>
> I like it. Thanks Glyn. :)
>
> It looks like stuff that the compiler will inline anyway because it  
> has
> full type information with everything being static and all. However,  
> it
> will change the way these are accessed -- instead of just doing  
> values,
> we need to make function calls...
>
> Perhaps it may work.
>
> Mike, would that be too much of a trouble? I as much as possible would
> like to avoid anonymous namespaces because of the ODR.
>
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
> <dmb...@fr...>
> +639287291459
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Hi,
I was just going through the test code and I found 2 difficulties:-
1. The http 1.0 implementation tests don't seem to fail if they are run with
no network connection (or didn't I wait long enough for them to time out?)
2. There doesn't seem to be any timeout or connection status feedback
available with the client object. For example, how does a client come to
know that a connection seems stalled and needs a restart (for example, an
intelligent download agent?). Where does this kind of info fit in the
basic_message hierarchy?  (I didn't find any appropriate functions or tests
for this kind of situation)

Have I looked at the right places for these things or have I missed them
completely?

Yours sincerely,
Divye Kapoor

-- 
Whether the chicken crossed the road or the road moved beneath the chicken
depends upon your frame of reference.
My official web site:
http://www.iitr.ernet.in/studenthomepages/homepages/061305

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Friday, April 18, 2008 11:46 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Implemented Rudimentary Unit 
> Test in branchhttp_integration
> 
> We have a bunch of Boost.Test - based tests written for 
> pion-net.  I'll be able to port these over as we move over 
> code.  Just haven't made it that far yet, as I keep getting 
> diverted with pesky work stuff =)
> 

Ah yes, pesky work stuff... Good thing I *need* the C++ Networking
library as part of the next project I'll be working on, so the tables
are now turned in my case -- the pesky work stuff *is* the C++
networking library. :D

I can definitely help with moving stuff over from libpion into
cpp-netlib -- just let me know which files you want to get into the
project so that I can pull them appropriately. Since we don't have any
SoC'ers helping around, I'll be glad to do the dirty work and try making
things compile *first* then work with the message abstraction(s) we
already have in the library.

Have a good one, and I certainly hope to see more code soon! :)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

We have a bunch of Boost.Test - based tests written for pion-net.   
I'll be able to port these over as we move over code.  Just haven't  
made it that far yet, as I keep getting diverted with pesky work stuff  
=)

On Apr 18, 2008, at 2:10 AM, Glyn Matthews wrote:

> Hi Mike,
>
> On 18/04/2008, Michael Dickey <mi...@mi...> wrote:
> Hi Dean,
>
> I haven't tried compiling anything yet since I was still working
> through the concept stage of "what goes where?"  (plus I still need to
> learn how to use bjam =)
>
> I would definitely recommend using unit testing to help you answer  
> this kind of question.  Write the tests as you hope/expect the  
> library to be used and then refactor your libpion code around the  
> tests (which should only have to change very little while you're  
> refactoring).   Also, as you update the unit tests in the  
> repository, you'll be able to get feedback from other developers and  
> potential users at an earlier stage than you would have otherwise.
>
>
> HTH,
> Glyn
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel

Hi Mike,

On 18/04/2008, Michael Dickey <mi...@mi...> wrote:
>
> Hi Dean,
>
> I haven't tried compiling anything yet since I was still working
> through the concept stage of "what goes where?"  (plus I still need to
> learn how to use bjam =)

I would definitely recommend using unit testing to help you answer this kind
of question.  Write the tests as you hope/expect the library to be used and
then refactor your libpion code around the tests (which should only have to
change very little while you're refactoring).   Also, as you update the unit
tests in the repository, you'll be able to get feedback from other
developers and potential users at an earlier stage than you would have
otherwise.

HTH,
Glyn

Hi Mike!

> -----Original Message-----
> From: Michael Dickey [mailto:mi...@mi...] 
> Sent: Friday, April 18, 2008 6:06 AM
> To: C++ Networking Library Developers Mailing List
> Cc: Dean Michael C. Berris
> Subject: Re: Implemented Rudimentary Unit Test in branch 
> http_integration
> 
> Hi Dean,
> 
> I haven't tried compiling anything yet since I was still 
> working through the concept stage of "what goes where?"  
> (plus I still need to learn how to use bjam =)
>

Ah, okay. :)

It's actually very nice -- once I learned about Bjam, I've never looked
back to Make and family. What specific problems are you having with it?
Perhaps we can collaborate on solving that problem over the list (or
privately) if you need any sort of help in that regard.

What would be nice to look at too would be using Boost.Test for writing
the unit tests. In the libs/network/test/ directory there are a handful
of tests that you can pattern the unit tests on. You can also look at
the Jamfile inside that directory to show how to add your tests to the
project.

> Glad to hear that you've moved things to the next level!  I 
> hope to invest some more time on it this weekend.
> 

It's my pleasure. I can hardly wait to play with more code from the
libpion library to be integrated into the library. :D

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

Hi Dean,

I haven't tried compiling anything yet since I was still working  
through the concept stage of "what goes where?"  (plus I still need to  
learn how to use bjam =)

Glad to hear that you've moved things to the next level!  I hope to  
invest some more time on it this weekend.

Take care,
-Mike

Ps. I'm still on the list, just back-logged =)

On Apr 16, 2008, at 1:28 AM, Dean Michael C. Berris wrote:
> Hi Everyone,
>
> I've made an effort to make the tests compile in the http_integration
> branch. Now we can make sure we can implement everything going forward
> with unit tests that build.
>
> I suggest that from here on out, we should strive to check in versions
> that have:
>
> 1) Unit tests written to cover as much (new) code as possible
> 2) Unit tests that at least build
> 3) In cases of unit tests that fail, it would be nice to know what
> particular problems you're encountering
>
> This is so that we can move forward in a pace that's less limiting --
> meaning we can make small changes left and right and keep everyone's
> copies "buildable" or at least "usable".
>
> Although there's not much there yet, it should be a good start.
>
> I'm CC'ing you Mike just in case you're not on the list anymore and
> would like to know what's going on. ;)
>
> In the next few days I'll be going to implement as much as I can in
> terms of unit tests -- we should be able to move forward in a better
> pace now that I'm pretty much devoted to this project as part of my
> professional endeavors. ;)
>
> Have a good day guys, and I hope this helps!
>
> --
> Dean Michael Berris
> Software Engineer, Friendster, Inc.
> <dmb...@fr...>
> +639287291459
>

Hi Everyone,

I've made an effort to make the tests compile in the http_integration
branch. Now we can make sure we can implement everything going forward
with unit tests that build.

I suggest that from here on out, we should strive to check in versions
that have:

1) Unit tests written to cover as much (new) code as possible
2) Unit tests that at least build
3) In cases of unit tests that fail, it would be nice to know what
particular problems you're encountering

This is so that we can move forward in a pace that's less limiting --
meaning we can make small changes left and right and keep everyone's
copies "buildable" or at least "usable".

Although there's not much there yet, it should be a good start.

I'm CC'ing you Mike just in case you're not on the list anymore and
would like to know what's going on. ;)

In the next few days I'll be going to implement as much as I can in
terms of unit tests -- we should be able to move forward in a better
pace now that I'm pretty much devoted to this project as part of my
professional endeavors. ;)

Have a good day guys, and I hope this helps!

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Glyn Matthews
> Sent: Tuesday, April 15, 2008 8:06 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> 
> Would it be possible to do something like the following:
> namespace http {
> namespace tags {
> struct message_tag {};
> struct message_tag_w {};
> }
> }
> 
> namespace http {
> namespace traits {
> template <
>     typename Tag
>     >
> struct delimiters;
> 
> 
> template <>
> struct delimiters<tags::message_tag> {
>     static char const *crlf() {
>         static const char *const crlf = "\x0D\x0A";
>         return crlf;
>     }
> };
> 
> 
> template <>
> struct delimiters<tags::message_tag_w> {
>     static wchar_t const *crlf() {
>         static const wchar_t *const crlf =  L"\x0D\x0A";
>         return crlf;
>     }
> };
> }
> }
>  

I like it. Thanks Glyn. :)

It looks like stuff that the compiler will inline anyway because it has
full type information with everything being static and all. However, it
will change the way these are accessed -- instead of just doing values,
we need to make function calls...

Perhaps it may work.

Mike, would that be too much of a trouble? I as much as possible would
like to avoid anonymous namespaces because of the ODR.

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

On 15/04/2008, Dean Michael C. Berris <dmb...@fr...> wrote:
>
>
> So this will have to come into some unnamed namespace to be included in
> every translation unit. Any other approach you can suggest?

Would it be possible to do something like the following:
namespace http {
namespace tags {
struct message_tag {};
struct message_tag_w {};
}
}

namespace http {
namespace traits {
template <
    typename Tag
    >
struct delimiters;

template <>
struct delimiters<tags::message_tag> {
    static char const *crlf() {
        static const char *const crlf = "\x0D\x0A";
        return crlf;
    }
};

template <>
struct delimiters<tags::message_tag_w> {
    static wchar_t const *crlf() {
        static const wchar_t *const crlf =  L"\x0D\x0A";
        return crlf;
    }
};
}
}

I'm back...

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Dean Michael C. Berris
> Sent: Tuesday, April 15, 2008 7:39 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
> Hi Glyn,
> 
> > -----Original Message-----
> > From: cpp...@li...
> > [mailto:cpp...@li...] On 
> Behalf Of 
> > Glyn Matthews
> > Sent: Tuesday, April 15, 2008 7:24 PM
> > To: C++ Networking Library Developers Mailing List
> > Subject: Re: [cpp-netlib-devel] Review of http::message
> > 
> [snip code]
> > 
> > 
> > Maybe I'm missing something here, but isn't it an error to 
> initialize 
> > a static non-integral type inside a struct definition?
> 
> I actually am not yet sure myself, but given 'char const * 
> const' is essentially a pointer type (which can be considered 
> an integral type) this just might work. This is one reason 
> I'd love to have unit tests too. ;)
> 
> Let me get back to you on this, I can spike it with a compiler.
>

EEP. Yes, you're right.

So this will have to come into some unnamed namespace to be included in
every translation unit. Any other approach you can suggest? 

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

Hi Glyn,

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Glyn Matthews
> Sent: Tuesday, April 15, 2008 7:24 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Review of http::message
> 
[snip code]
> 
> 
> Maybe I'm missing something here, but isn't it an error to 
> initialize a static non-integral type inside a struct definition?

I actually am not yet sure myself, but given 'char const * const' is
essentially a pointer type (which can be considered an integral type)
this just might work. This is one reason I'd love to have unit tests
too. ;)

Let me get back to you on this, I can spike it with a compiler.

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459

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

cpp-netlib-devel Mailing List for C++ Network Library (Page 49)

cpp-netlib-devel — Developers Mailing List