cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] mime (http integration)

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

Hi Dean and everyone,

On Wed, Sep 3, 2008 at 7:12 AM, Dean Michael C. Berris <
dmb...@fr...> wrote:

>
> This time I think we may have to move the mime processing code outside
> of boost/network/protocol and just move it into boost/network/utils or
> something similar. A lot of the URI parsing stuff can also be moved out
> of boost/network/protocol/http and into its own component into
> boost/network/utils.


Hmmm, isn't MIME itself a protocol (
http://en.wikipedia.org/wiki/Category:Application_layer_protocols)?

And speaking of utils, the message encoding/decoding (such as to/from base64
that you have in http) could also be added there, right?


>
>
> I'll think more about it before making any changes/moves.
>
> It would also be a good idea to branch off for MIME development
> (mime_integration) perhaps.
>
> More about it as my brain starts picking up. ;)
>

Yes, maybe branching off for MIME would be a good idea -- once we've decided
where to put it hehe...

Cheers,
Allister

Re: [cpp-netlib-devel] Dispatch Table Example

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

Hi Dean,

On Wed, Sep 3, 2008 at 11:11 AM, Dean Michael Berris <mik...@gm...
> wrote:

> Hi Divye,
>
> On Wed, Sep 3, 2008 at 2:41 AM, Divye Kapoor <div...@gm...>
> wrote:
> > Hello all,
> >    I've just added a dispatch_table example to the repository. Please
> have a
> > look at the code and suggest any improvements.
> >
>
> Sweet! Which branch did you put it in?
>

http_integration branch -> libs\network\example


> > While testing this example, I came across an oddity. I am using the same
> > functions as the http_client example. However, when I try to run
> > dispatch_table.exe, I need to provide it elevated privileges on Vista.
> The
> > same is not needed for http_client.exe. Why so? Any ideas?
> >
>
> I think it's because you're using Vista... Try it in Linux instead. :P
>

Maybe I really should ;-)


>
> But seriously, I think this is not something we might need to worry
> about. If it works even with elevation, then I think that's good
> enough for me. :)
>

Same here. :-)

Divye

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

Re: [cpp-netlib-devel] localhost_tests cleanup

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

Hi Kim,

Thanks, I'll apply the patch and test. If the tests pass, then I guess
it should be alright to commit.

I just got a message from Sourceforge though that write access will be
disabled until further notice, so it may take a while before this gets
into the repository.

More later! :)

On Wed, Sep 3, 2008 at 5:01 AM, Kim Gräsman <kim...@gm...> wrote:
> Hello,
>
> I've spent a couple of hours getting used to Boost, cpp-netlib, etc,
> and spent those cleaning up localhost_tests.cpp. Here's a patch that
> does a lot:
>
> - extracts http_test_server.hpp wrapping ShellExecuteEx/fork
> - http_test_server no longer stops with an error dialog if Python is
> not installed, but rather fails with an error message on the console
> - uses global fixture for starting/stopping the Python test server
> (independent of test run order)
> - cleaned some file i/o out of text_file_query and binary_file_query
> into helper function readfile
> - consistent tab size in localhost_tests.cpp
> - added adjust_lineendings, used with text_file_query to make the
> source data match the output from the Python server (LF-only
> line-endings)
>
> I wish I could've offered these one-by-one, but it would turn into a
> versioning nightmare to apply the patches in order. I think most of
> the changes are benign, I'm a little doubtful of the last one, but
> until I've fully understood Divye, this is a workaround to make it
> right on Windows.
>
> Hope it helps,
> - Kim
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>
>



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

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Kim,

On Wed, Sep 3, 2008 at 4:29 AM, Kim Gräsman <kim...@gm...> wrote:
>
> On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote:
>>
>> As of now, we are not touching the response body given by the server. Right
>> now, we know that the python server is returning fewer characters of the
>> body than expected and we are retaining it bit for bit, allowing the test to
>> fail on Windows.
>
> Right. But I'm suggesting we should start from data that the Python
> server does not destroy, allowing the test to *succeed* on all
> platforms.
>

Actually, I wouldn't worry about this -- we're hitting a bug in a
third-party application that we so happen use in our
development/testing. It's by no means a big deal that we're hitting
that bug.

Although I understand the importance of keeping the build/test clean,
we can mark this as an expected failure in Windows+Python(2.5/2.6) --
which by no means reflects as a bug in cpp-netlib.

>> However, if we do need to process the body at some other
>> stage, say to support multipart responses,  it would be helpful to retain
>> the test with the CRLF line endings to ensure that non-native line endings
>> are being processed properly by the library while handling the body.
>
> As it currently stands, the library will only ever receive LF from the
> Python server, no matter what the source data looks like, as some
> Python library strips CR from all line ends.
>

Not in Linux.

> I'm not sure what you mean by "non-native line endings", but the
> Python server will always return LF-only (until that bug is fixed in
> Python, which looks like it could take a while) so the CRLF file will
> only serve to test Python, not our client library...
>

This is in Windows only, which is not a big deal.

> Or am I still missing something?
>

I think it's all about whether we want to live with the test failure
in Windows based on a perfectly valid test that exposes a bug in
Python in Windows. In this case I think it's alright for us to live
with it -- we can mark it as an expected failure if we're in Windows.

Perhaps a patch to the test to reflect this would be very welcome. :)

HTH

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

Re: [cpp-netlib-devel] Dispatch Table Example

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

Hi Divye,

On Wed, Sep 3, 2008 at 2:41 AM, Divye Kapoor <div...@gm...> wrote:
> Hello all,
>    I've just added a dispatch_table example to the repository. Please have a
> look at the code and suggest any improvements.
>

Sweet! Which branch did you put it in?

> While testing this example, I came across an oddity. I am using the same
> functions as the http_client example. However, when I try to run
> dispatch_table.exe, I need to provide it elevated privileges on Vista. The
> same is not needed for http_client.exe. Why so? Any ideas?
>

I think it's because you're using Vista... Try it in Linux instead. :P

But seriously, I think this is not something we might need to worry
about. If it works even with elevation, then I think that's good
enough for me. :)

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

Re: [cpp-netlib-devel] mime (http integration)

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

Hi Allister,

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Allister Levi Sanchez
> Sent: Wednesday, September 03, 2008 8:21 AM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] mime (http integration)
> 
> Oops, I forgot: it's in boost/network/protocol/mime.hpp
> 

Thanks,

This time I think we may have to move the mime processing code outside
of boost/network/protocol and just move it into boost/network/utils or
something similar. A lot of the URI parsing stuff can also be moved out
of boost/network/protocol/http and into its own component into
boost/network/utils.

I'll think more about it before making any changes/moves.

It would also be a good idea to branch off for MIME development
(mime_integration) perhaps.

More about it as my brain starts picking up. ;)

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

Re: [cpp-netlib-devel] Packaging 0.2

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

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Glyn Matthews
> Sent: Wednesday, September 03, 2008 3:22 AM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Packaging 0.2
> 
> 
> 
> 2008/9/2 Glyn Matthews <gly...@gm...>
[snip]
> 
> OK, merged doc changes into trunk, made docs branch for HTML, 
> then I copied a new branch from trunk to tag version 0.2.  
> I'm having a whole load of problems because sf is really slow 
> and I find the way to publish a release rather confusing 
> (doesn't help that its quite late).  Dean, can you finish 
> this up?  Everything you need to do it is in tags/release/0.2.
> 

Thanks, I'll do the packaging today.

Update everyone soon as this is done! :)


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

Re: [cpp-netlib-devel] mime (http integration)

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

Oops, I forgot: it's in boost/network/protocol/mime.hpp

On Wed, Sep 3, 2008 at 2:15 AM, Allister Levi Sanchez <
all...@gm...> wrote:

> Hi,
>
> I've committed my first attempt at MIME.  Sorry I haven't even compiled it
> yet (bad practice, I promise won't happen again!) but I have to sleep for
> now and hopefully get your comments, suggestions and modifications/patches
> tomorrow after work :-)
>
> Cheers,
> Allister
>
>

[cpp-netlib-devel] mime (http integration)

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

Hi,

I've committed my first attempt at MIME.  Sorry I haven't even compiled it
yet (bad practice, I promise won't happen again!) but I have to sleep for
now and hopefully get your comments, suggestions and modifications/patches
tomorrow after work :-)

Cheers,
Allister

[cpp-netlib-devel] localhost_tests cleanup

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

Hello,

I've spent a couple of hours getting used to Boost, cpp-netlib, etc,
and spent those cleaning up localhost_tests.cpp. Here's a patch that
does a lot:

- extracts http_test_server.hpp wrapping ShellExecuteEx/fork
- http_test_server no longer stops with an error dialog if Python is
not installed, but rather fails with an error message on the console
- uses global fixture for starting/stopping the Python test server
(independent of test run order)
- cleaned some file i/o out of text_file_query and binary_file_query
into helper function readfile
- consistent tab size in localhost_tests.cpp
- added adjust_lineendings, used with text_file_query to make the
source data match the output from the Python server (LF-only
line-endings)

I wish I could've offered these one-by-one, but it would turn into a
versioning nightmare to apply the patches in order. I think most of
the changes are benign, I'm a little doubtful of the last one, but
until I've fully understood Divye, this is a workaround to make it
right on Windows.

Hope it helps,
- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Divye,

On Tue, Sep 2, 2008 at 17:41, Divye Kapoor <div...@gm...> wrote:
>
>> > I would not advise such a commit as it atleast prevents *us* from
>> > munging
>> > line endings while handling text bodies.
>>
>> I'm not sure I understand... Are you saying it could mask bugs in
>> cpp-netlib? Could you elaborate?
>
> As of now, we are not touching the response body given by the server. Right
> now, we know that the python server is returning fewer characters of the
> body than expected and we are retaining it bit for bit, allowing the test to
> fail on Windows.

Right. But I'm suggesting we should start from data that the Python
server does not destroy, allowing the test to *succeed* on all
platforms.

> However, if we do need to process the body at some other
> stage, say to support multipart responses,  it would be helpful to retain
> the test with the CRLF line endings to ensure that non-native line endings
> are being processed properly by the library while handling the body.

As it currently stands, the library will only ever receive LF from the
Python server, no matter what the source data looks like, as some
Python library strips CR from all line ends.

I'm not sure what you mean by "non-native line endings", but the
Python server will always return LF-only (until that bug is fixed in
Python, which looks like it could take a while) so the CRLF file will
only serve to test Python, not our client library...

Or am I still missing something?

Thanks,
- Kim

Re: [cpp-netlib-devel] Dispatch Table Example

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

Hi Divye,

On Tue, Sep 2, 2008 at 20:41, Divye Kapoor <div...@gm...> wrote:
> Hello all,
>    I've just added a dispatch_table example to the repository. Please have a
> look at the code and suggest any improvements.
>
> While testing this example, I came across an oddity. I am using the same
> functions as the http_client example. However, when I try to run
> dispatch_table.exe, I need to provide it elevated privileges on Vista. The
> same is not needed for http_client.exe. Why so? Any ideas?

The .exe name is probably triggering one of the UAC heuristics; the OS
checks the filename of every launched executable, looking for keywords
that give it away as an installer. Apparently "patch" is one of the
trigger words [1], so "dis*patch*_table.exe" is incorrectly classified
as requiring elevation.

Best bet is probably to change the name of the .cpp file and/or .exe.
The only alternative I know of is to add a UAC manifest either
embedded or side-by-side, but that complicates build and deployment
significantly, compared to the current...

- Kim

[1] http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1613234&SiteID=1

Re: [cpp-netlib-devel] Packaging 0.2

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

2008/9/2 Glyn Matthews <gly...@gm...>

> Hi Dean,
>
> 2008/9/2 Dean Michael C. Berris <dmb...@fr...>
>
>> Hi Guys,
>>
>> I've read through the documentation from the docs branch, and I must say
>> I'm pleased with the content in the quickbook files.
>>
>> Glyn, should we merge the docs into trunk and package 0.2 for release?
>
> Yes, though they're still incomplete :)  From now on, assume that you can
> always merge the docs.
>
>
>>
>> I imagine we should be generating HTML documentation that should go into
>> the docs/ directory and checked into the subversion repository. Would
>> you mind doing this as well?
>>
>
> Yeah, I can't do it from work so I'll take a look this evening.
>

OK, merged doc changes into trunk, made docs branch for HTML, then I copied
a new branch from trunk to tag version 0.2.  I'm having a whole load of
problems because sf is really slow and I find the way to publish a release
rather confusing (doesn't help that its quite late).  Dean, can you finish
this up?  Everything you need to do it is in tags/release/0.2.

:(  thanks.
G

[cpp-netlib-devel] Dispatch Table Example

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

Hello all,
   I've just added a dispatch_table example to the repository. Please have a
look at the code and suggest any improvements.

While testing this example, I came across an oddity. I am using the same
functions as the http_client example. However, when I try to run
dispatch_table.exe, I need to provide it elevated privileges on Vista. The
same is not needed for http_client.exe. Why so? Any ideas?

Divye

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

Re: [cpp-netlib-devel] localhost_tests failures

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

On Tue, Sep 2, 2008 at 7:19 PM, Kim Gräsman <kim...@gm...> wrote:

> Hi Divye,
>
> On Tue, Sep 2, 2008 at 15:43, Divye Kapoor <div...@gm...> wrote:
> >>
> >> Attached is a patch for the modified test.xml and adjusted
> >> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
> >> handling changes only in line endings, so whoever commits this may
> >> need to alter test.xml manually to make it use Unix line-endings.
> >
> > I would not advise such a commit as it atleast prevents *us* from munging
> > line endings while handling text bodies.
>
> I'm not sure I understand... Are you saying it could mask bugs in
> cpp-netlib? Could you elaborate?
>

As of now, we are not touching the response body given by the server. Right
now, we know that the python server is returning fewer characters of the
body than expected and we are retaining it bit for bit, allowing the test to
fail on Windows. However, if we do need to process the body at some other
stage, say to support multipart responses,  it would be helpful to retain
the test with the CRLF line endings to ensure that non-native line endings
are being processed properly by the library while handling the body.

Divye

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

Re: [cpp-netlib-devel] Packaging 0.2

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

Hi Divye,

2008/9/2 Divye Kapoor <div...@gm...>

>
>
> On Tue, Sep 2, 2008 at 6:27 PM, Glyn Matthews <gly...@gm...>wrote:
>
>>
>>
>> More examples :)
>>
>
> I've written a simple dispatch table kind of function to illustrate string
> based dispatch to the http::client. I don't know how to structure this as a
> real world example. Should I try merging the dispatch table code with the
> http_client example so that it handles different methods (say by having a
> command line argument --method GET/POST/PUT etc.) or keep it separate?
>

Please keep it separate.  I've added a section to the docs which walks
through the http_client example, so its best to keep this as simple as
possible.

G

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Divye,

On Tue, Sep 2, 2008 at 15:43, Divye Kapoor <div...@gm...> wrote:
>>
>> Attached is a patch for the modified test.xml and adjusted
>> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
>> handling changes only in line endings, so whoever commits this may
>> need to alter test.xml manually to make it use Unix line-endings.
>
> I would not advise such a commit as it atleast prevents *us* from munging
> line endings while handling text bodies.

I'm not sure I understand... Are you saying it could mask bugs in
cpp-netlib? Could you elaborate?

> Even though it might seem nice to
> resolve this issue via a file that doesn't have CRLF line breaks, I would
> suggest that it be resolved by changing the test case to reflect the reduced
> file size in the case of Windows/Python combination.

True, that seems like a safer workaround. I'll get to it.

- Kim

Re: [cpp-netlib-devel] Packaging 0.2

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

On Tue, Sep 2, 2008 at 6:27 PM, Glyn Matthews <gly...@gm...>wrote:

>
>
> More examples :)
>

I've written a simple dispatch table kind of function to illustrate string
based dispatch to the http::client. I don't know how to structure this as a
real world example. Should I try merging the dispatch table code with the
http_client example so that it handles different methods (say by having a
command line argument --method GET/POST/PUT etc.) or keep it separate?

Divye


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

Re: [cpp-netlib-devel] localhost_tests failures

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

On Tue, Sep 2, 2008 at 6:48 PM, Kim Gräsman <kim...@gm...> wrote:

> I figured out one workaround -- save test.xml with Unix line-endings
> (i.e. LF only). That way Python gets what it expects, and the C++ code
> reading the file sees the same thing.
>
> <snip>


> Attached is a patch for the modified test.xml and adjusted
> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
> handling changes only in line endings, so whoever commits this may
> need to alter test.xml manually to make it use Unix line-endings.
>

I would not advise such a commit as it atleast prevents *us* from munging
line endings while handling text bodies. Even though it might seem nice to
resolve this issue via a file that doesn't have CRLF line breaks, I would
suggest that it be resolved by changing the test case to reflect the reduced
file size in the case of Windows/Python combination.

Divye

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

Re: [cpp-netlib-devel] localhost_tests failures

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

On Tue, Sep 2, 2008 at 15:34, Kim Gräsman <kim...@gm...> wrote:
>
> So, if you would want to commit this, please do as Glyn suggests, and
> apply the svn:eol-style property to test.xml, set to LF.

I tried, but I can't get it to follow through in a .patch -- the
propset gets recorded, but it doesn't update the line endings in
place... Anyway, please change line endings and the EOL style
property, and the committed version should build and run tests
successfully out of the box.

Thanks,
- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Glyn,

On Tue, Sep 2, 2008 at 15:28, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
> 2008/9/2 Kim Gräsman <kim...@gm...>
>>
>> Attached is a patch for the modified test.xml and adjusted
>> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
>> handling changes only in line endings, so whoever commits this may
>> need to alter test.xml manually to make it use Unix line-endings.
>
> I don't think that is necessary, I think its possible to set it using
> svn:eol-style:
>
> http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5

That looks like it should keep it correct moving forward! I know my
patch files contains Unix line-endings for the replaced lines, but it
didn't seem to come through when I applied it -- that's probably
because the default EOL style is native and so TSVN translates it
(helpfully) into CRLF.

So, if you would want to commit this, please do as Glyn suggests, and
apply the svn:eol-style property to test.xml, set to LF.

Thanks,
- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi,

2008/9/2 Kim Gräsman <kim...@gm...>

>
> Attached is a patch for the modified test.xml and adjusted
> localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
> handling changes only in line endings, so whoever commits this may
> need to alter test.xml manually to make it use Unix line-endings.
>

I don't think that is necessary, I think its possible to set it using
svn:eol-style:

http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5

G

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Dean,

> The issue has something to do with Python bugs that Divye has posted to the list earlier.

Ah, found it now, you ironed this out just before I joined!

> There's currently no workaround for this, since we haven't been implementing an HTTP Server in the library yet. At any rate, this doesn't manifest itself in Linux.

I figured out one workaround -- save test.xml with Unix line-endings
(i.e. LF only). That way Python gets what it expects, and the C++ code
reading the file sees the same thing.

For the ones with no body, that's because my *Python* installation is
in Program Files, so both Python and the cpp-netlib source need to
live in a space-free path. Ugh. I'll reinstall Python.

Attached is a patch for the modified test.xml and adjusted
localhost_tests.cpp. Unfortunately, TortoiseSVN seems to have trouble
handling changes only in line endings, so whoever commits this may
need to alter test.xml manually to make it use Unix line-endings.

This seems like a nice thing to get in place, I have some more coming.

- Kim

Re: [cpp-netlib-devel] Packaging 0.2

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

Hi Dean,

2008/9/2 Dean Michael C. Berris <dmb...@fr...>

> Hi Guys,
>
> I've read through the documentation from the docs branch, and I must say
> I'm pleased with the content in the quickbook files.
>
> Glyn, should we merge the docs into trunk and package 0.2 for release?

Yes, though they're still incomplete :)  From now on, assume that you can
always merge the docs.


>
> I imagine we should be generating HTML documentation that should go into
> the docs/ directory and checked into the subversion repository. Would
> you mind doing this as well?
>

Yeah, I can't do it from work so I'll take a look this evening.


>
> I've elected to postpone the asynchronous body handler implementation
> for later. What I have been thinking about is caching the resolved
> endpoints instead of having to perform a query everytime a request is
> performed, and finally implementing that constructor for the
> http::client (to enable/disable features).
>

Sounds good.


>
> It's a little early I know, but comments on what you guys think should
> be in 0.3 would be very nice to know. :)
>

More examples :)


>
> Have a good one!
>

You too,
G

[cpp-netlib-devel] Packaging 0.2

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

Hi Guys,

I've read through the documentation from the docs branch, and I must say
I'm pleased with the content in the quickbook files.

Glyn, should we merge the docs into trunk and package 0.2 for release?

I imagine we should be generating HTML documentation that should go into
the docs/ directory and checked into the subversion repository. Would
you mind doing this as well?

I've elected to postpone the asynchronous body handler implementation
for later. What I have been thinking about is caching the resolved
endpoints instead of having to perform a query everytime a request is
performed, and finally implementing that constructor for the
http::client (to enable/disable features).

It's a little early I know, but comments on what you guys think should
be in 0.3 would be very nice to know. :)

Have a good one!

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