cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

Hi Kim,

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

> On Thu, Sep 4, 2008 at 13:17, Kim Gräsman <kim...@gm...> wrote:
>
> I meant to include a link as well -- James Shore is an XP practitioner
> and spokesperson who always seems to hit the nail on the head:
> http://jamesshore.com/Agile-Book/documentation.html
>

I (briefly) took a look and it seems like he's arguing that providing
documentation for the sake of itself doesn't work.  I hope we're taking a
more pro-active approach to documentation.  As I mentioned in my previous
response, the API and the motivation/rationale/examples need to complement
each other.  I also hope that poor documentation, as with code, is discussed
and reviewed on the mailing list so we can avoid the scenario that he
describes.

Regards,
Glyn

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

Hi Kim,

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

> Hi all,
>
> Personally, I'd like to keep comments and docs to an absolute minimum.
> Method comments are at best redundant and at worst misleading, IFF the
> methods are well named and well designed.
>

I disagree.  That's a pretty big IFF and since language is ambiguous, its
not realistic in my view.  Furthermore, I think its important to document
side-effect and pre-/post- conditions.  This is something that can't be done
by good naming alone.


>
> My take is to reserve comments for exceptional cases (e.g. why we
> can't test for preservation of CRLF on Windows, due to a bug in the
> Python HTTP server), and focus on naming to convey meaning (e.g. let
> test names spell out their premise).
>
> As for documentation, rationale and high-level docs tend to be more
> stable, so I'd focus on that first.  Since we're shipping a library,
> though, it makes sense to provide some detailed API documentation. Not
> sure what form is easiest to digest.


Yep.  These can be done separately.  I've added a reference section which is
where I intend to put the API docs so its bundled with the rest of the
docs.  I think they need to be provided to complement each other.  Many
boost libraries do this and I think it works.


> One benefit of Doxygen-style solutions is that the documentation is
> closer to the code, so it's easier to see and fix discrepancies. A
> drawback, on the other hand, is that huge block comments can obscure
> the actual source code.


I think the first one trumps the second one.

Glyn

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

On Thu, Sep 4, 2008 at 13:17, Kim Gräsman <kim...@gm...> wrote:
>
> As for documentation, rationale and high-level docs tend to be more
> stable, so I'd focus on that first. Since we're shipping a library,
> though, it makes sense to provide some detailed API documentation. Not
> sure what form is easiest to digest.[..]

... and produce :)

I meant to include a link as well -- James Shore is an XP practitioner
and spokesperson who always seems to hit the nail on the head:
http://jamesshore.com/Agile-Book/documentation.html

Cheers,
- Kim

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

Hi all,

Personally, I'd like to keep comments and docs to an absolute minimum.
Method comments are at best redundant and at worst misleading, IFF the
methods are well named and well designed.

My take is to reserve comments for exceptional cases (e.g. why we
can't test for preservation of CRLF on Windows, due to a bug in the
Python HTTP server), and focus on naming to convey meaning (e.g. let
test names spell out their premise).

As for documentation, rationale and high-level docs tend to be more
stable, so I'd focus on that first. Since we're shipping a library,
though, it makes sense to provide some detailed API documentation. Not
sure what form is easiest to digest.

One benefit of Doxygen-style solutions is that the documentation is
closer to the code, so it's easier to see and fix discrepancies. A
drawback, on the other hand, is that huge block comments can obscure
the actual source code.

FWIW,
- Kim

On Wed, Sep 3, 2008 at 11:10, Dean Michael Berris
<mik...@gm...> wrote:
> Hi Guys,
>
> I'm just thinking aloud here, but should we have explicit policies
> about the code/documentation quality?
>
> For instance, I have been remiss with inline documentation which makes
> it really hard to go back to the code and generate explicit
> relationships with existing tools. What would really help I think is
> if we started documenting each method/class/template with Doxygen
> comments.
>
> This is because now we're reaching that 'handful of developers'
> number, and it's really getting hard (even for me) to remember where
> things are and which things did what and what I should change where.
>
> I'd like to hear your thoughts about the issue, and how you propose we
> go about with generating the documentation of the source code.
>
> HTH
>
> --
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.

[cpp-netlib-devel] [http_integration] Resolved Endpoint Caching and Redirection [300..307] Support in r83

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

Hi Guys,

These two features weren't as hard to implement as I thought, so I
went ahead and committed revision 83 which includes caching the
resolved endpoints, and handling 300..307 redirects from the server.

I also moved the uri parsing functionality into its own method from
http/impl/request.hpp still part of the http::request class. Next
steps should be to move it out completely and into the
network/utils/uri/ directory. I believe someone else has mentioned
that they already have an implementation that they want to make part
of the library -- should we do that anytime soon?

If not I can start collecting utility functions and move those into
network/utils/... -- the only thing I can think of right now are the
URI parsing functions, but I guess there's more that can be factored
out and made into utilities.

HTH

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

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

On Wed, Sep 3, 2008 at 7:10 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/9/3 Dean Michael Berris <mik...@gm...>
>>
>> Hi Guys,
>>
>> I'm just thinking aloud here, but should we have explicit policies
>> about the code/documentation quality?
>
> Yeah, I agree.  I think its a bit broader than a doxygen policy.  Boost
> itself does have some requirements:
>
> http://www.boost.org/development/requirements.html#Documentation
>

Right. I should go take a better read of this document. :-)

>>
>> For instance, I have been remiss with inline documentation which makes
>> it really hard to go back to the code and generate explicit
>> relationships with existing tools. What would really help I think is
>> if we started documenting each method/class/template with Doxygen
>> comments.
>
> This much seems only reasonable, I think.  The above link described exactly
> what needs to be documented for each method/class/template.
>

Sweet. I'll go look into it.

>>
>> I'd like to hear your thoughts about the issue, and how you propose we
>> go about with generating the documentation of the source code.
>
> Boost.Asio has some scripts which generates generates HTML from doxygen
> comments and converts it to boostbook.  Some headers and examples are
> included in the documentation.
>
> http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/reference.html
>
> I had envisioned having something similar to this for our project.
>

Nice! Should we stick with non-doxygen generated documentation and do
the same thing Asio does?

Thanks for the quick response Glyn.

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

Re: [cpp-netlib-devel] [RFC] Doxygen Policy

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

Dean,

2008/9/3 Dean Michael Berris <mik...@gm...>

> Hi Guys,
>
> I'm just thinking aloud here, but should we have explicit policies
> about the code/documentation quality?
>

Yeah, I agree.  I think its a bit broader than a doxygen policy.  Boost
itself does have some requirements:

http://www.boost.org/development/requirements.html#Documentation


> For instance, I have been remiss with inline documentation which makes
> it really hard to go back to the code and generate explicit
> relationships with existing tools. What would really help I think is
> if we started documenting each method/class/template with Doxygen
> comments.
>

This much seems only reasonable, I think.  The above link described exactly
what needs to be documented for each method/class/template.


>
> I'd like to hear your thoughts about the issue, and how you propose we
> go about with generating the documentation of the source code.


Boost.Asio has some scripts which generates generates HTML from doxygen
comments and converts it to boostbook.  Some headers and examples are
included in the documentation.

http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/reference.html

I had envisioned having something similar to this for our project.

Glyn

Re: [cpp-netlib-devel] localhost_tests failures

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

On Wed, Sep 3, 2008 at 5:21 PM, Kim Gräsman <kim...@gm...> wrote:
>
> On Wed, Sep 3, 2008 at 10:19, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> Are we getting closer? :)
>>
>> I personally think just marking it an expected failure on Windows with
>> explicit documentation stating the rationale (citing the Python bug)
>> would be sufficient.
>
> That's what I meant, sorry if I wasn't clear.
>

It's alright. :)

> Now I understand what the test is there for, it didn't occur to me
> earlier that there should be no difference between text/binary, except
> /possibly/ for handling of line endings -- if the client treats them
> both as binary, then that's good. Time to make the server do the same
> ;-)
>

Right. :-)

It would be good to have an HTTP Server part of the library, but it's
something that I have yet to get to. Right now I'm still having fun
with the client and implementing a client, and it's a good change of
pace for me since I've been too involved in developing an HTTP Server
from scratch as well for the longest time. ;-)

> Thanks,
> - Kim
>

Thank you too. :-)

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

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Dean,

On Wed, Sep 3, 2008 at 10:19, Dean Michael Berris
<mik...@gm...> wrote:
>
>> Are we getting closer? :)
>
> I personally think just marking it an expected failure on Windows with
> explicit documentation stating the rationale (citing the Python bug)
> would be sufficient.

That's what I meant, sorry if I wasn't clear.

Now I understand what the test is there for, it didn't occur to me
earlier that there should be no difference between text/binary, except
/possibly/ for handling of line endings -- if the client treats them
both as binary, then that's good. Time to make the server do the same
;-)

Thanks,
- Kim

Re: [cpp-netlib-devel] Release 0.2 Out

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

Thanks Dean!

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

> Hi Everyone,
>
> I've just packaged and uploaded release 0.2 which adds just the
> generated documentation and documentation source. We should be able to
> move forward and implement the following things which will go out in
> 0.3:
>
> - http::client constructor to allow:
>  * redirect following (follow 3xx HTTP responses)
>  * resolved endpoint caching
> - basic mime support
> - more unit tests for http::client
> - examples
>  * dispatcher table example
>  * improved wget replacement, using 3xx following
>

That would be great progress :)

I hope by release 0.3 we can announce this on the Boost C++ Developers
> Mailing List to gauge interest and get more support. :)
>

Yeah, good idea.

Glyn

[cpp-netlib-devel] [RFC] Doxygen Policy

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

Hi Guys,

I'm just thinking aloud here, but should we have explicit policies
about the code/documentation quality?

For instance, I have been remiss with inline documentation which makes
it really hard to go back to the code and generate explicit
relationships with existing tools. What would really help I think is
if we started documenting each method/class/template with Doxygen
comments.

This is because now we're reaching that 'handful of developers'
number, and it's really getting hard (even for me) to remember where
things are and which things did what and what I should change where.

I'd like to hear your thoughts about the issue, and how you propose we
go about with generating the documentation of the source code.

HTH

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

[cpp-netlib-devel] Release 0.2 Out

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

Hi Everyone,

I've just packaged and uploaded release 0.2 which adds just the
generated documentation and documentation source. We should be able to
move forward and implement the following things which will go out in
0.3:

- http::client constructor to allow:
  * redirect following (follow 3xx HTTP responses)
  * resolved endpoint caching
- basic mime support
- more unit tests for http::client
- examples
  * dispatcher table example
  * improved wget replacement, using 3xx following

Tentative schedule for 0.3 release is Sept. 15. :)

We'd like more help with:
- documentation
- testing
- specific implementation

I hope by release 0.3 we can announce this on the Boost C++ Developers
Mailing List to gauge interest and get more support. :)

Have a good day everyone!

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

Re: [cpp-netlib-devel] localhost_tests failures

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

On Wed, Sep 3, 2008 at 4:08 PM, Kim Gräsman <kim...@gm...> wrote:
>
>> The premise of the test is:
>> - when we request a file that has CRLF line endings, we get it with
>> CRLF line endings
>> - cpp-netlib will not fail because having CRLF line endings in the
>> body should be acceptable
>> - CRLF line endings are preserved when the body of an http::response
>> is retrieved.
>
> Ah, are the CRLF line endings the primary feature of this test?
>

Okay, a bit of history required I think...

In the first incarnation (very early implementation) of the
http::client, it performed a getline(stream, string) which stripped
the line endings from responses. So Divye implemented a test which
exposes this bug in the form of files with CRLF line endings.

> It hasn't occurred to me, but text_file_query probably implies
> something about the line endings...
>

Right, I think the name would was a little vague too now that I think
about it. ;-)

> Maybe both should be covered, e.g.
>
>  text_query_crlf_preserved
>  text_query_lf_preserved
>
> The first would have to be ignored on Windows, as there's no way of
> making that pass with the current Python implementation.
>

Maybe... But really, I think we shouldn't make too much of a case
regarding getting around Python especially since they won't be fixing
that bug and since we're only interested in making sure we *do* get
the CRLF's when they go through the wire without causing the client to
break.

> Are we getting closer? :)

I personally think just marking it an expected failure on Windows with
explicit documentation stating the rationale (citing the Python bug)
would be sufficient.

Although a test case where we have just LF's would be alright as well.

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

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Dean,

On Wed, Sep 3, 2008 at 09:28, Dean Michael Berris
<mik...@gm...> wrote:
>
> We're not testing the serving of the file -- because that's Python's
> domain, and we're not testing the Python server -- but rather we're
> testing the reception of the file to make sure that *if* and *when*
> the file contains CRLF line endings, that we catch it as is.

Right.

> The premise of the test is:
> - when we request a file that has CRLF line endings, we get it with
> CRLF line endings
> - cpp-netlib will not fail because having CRLF line endings in the
> body should be acceptable
> - CRLF line endings are preserved when the body of an http::response
> is retrieved.

Ah, are the CRLF line endings the primary feature of this test?

It hasn't occurred to me, but text_file_query probably implies
something about the line endings...

Maybe both should be covered, e.g.

  text_query_crlf_preserved
  text_query_lf_preserved

The first would have to be ignored on Windows, as there's no way of
making that pass with the current Python implementation.

Are we getting closer? :)

Thanks,
- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

On Wed, Sep 3, 2008 at 3:00 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Sep 3, 2008 at 08:44, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> I don't see how that's an improvement over saving test.xml with
>>> LF-only line endings, and get consistent test results...? I understood
>>> Divye's point to be that if we did that, we would mask something else.
>>>
>>
>> It's not about changing the test data to make sure the tests run, it's
>> more about making sure we get the correct data that we expect from the
>> HTTP Server -- and if I requested for a file that has CRLF line
>> endings in from the server, that I would get the exact same file if I
>> read it from disk in binary mode.
>
> The thing is, the server you're using cannot serve a file containing
> CRLF "for technical reasons" -- wouldn't it seem better to base the
> test off a file with LF only?
>
> That way you preserve the premise of the test, but change the details
> to compensate for the "technical reasons", so that the test is still
> valid.
>

We're not testing the serving of the file -- because that's Python's
domain, and we're not testing the Python server -- but rather we're
testing the reception of the file to make sure that *if* and *when*
the file contains CRLF line endings, that we catch it as is.

The premise of the test is:
- when we request a file that has CRLF line endings, we get it with
CRLF line endings
- cpp-netlib will not fail because having CRLF line endings in the
body should be acceptable
- CRLF line endings are preserved when the body of an http::response
is retrieved.

Of course, it assumes that the HTTP server will serve the file
correctly. In this case the problem is no longer the client, but the
server. In which case, since this failure only happens in Windows with
Python, and that it's a known bug in the server, then it's best that
we mark it as an expected failure due to a bug in the third party. If
there was anything that was going to be fixed, it is the Python
server, not the unit test or the test data. ;-)

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

Re: [cpp-netlib-devel] localhost_tests cleanup

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

Hi Divye,

On Wed, Sep 3, 2008 at 08:43, Divye Kapoor <div...@gm...> wrote:
>
> I tried extracting the ShellExecuteEx and Fork into a separate header file
> and creating the fixture but I was continually running into segmentation
> faults. So, I put it aside for a while. Thanks for the patch!

Oops--let's hope that doesn't show again! I haven't been able to run
the tests on Linux, so I've done my best to move the source as it was
into the new header.

> I think Dean's made a pretty good explanation of what I'm trying to convey.
> The file size test that fails on Windows actually passes on Linux because
> the linux version of the python library doesn't convert the CRLF to a single
> LF. Its a known bug in the Python library that causes the file size mismatch
> on windows. Although it helps to keep the tests clean, the text file
> transfer test is an expected failure on Windows. It would be better to mark
> this test as an expected failure in the test suite rather than making up for
> the shortcomings of the Python server.

As we've hashed out in other threads, I disagree. I think an expected
failure-test is pretty useless.

- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Divye,

On Wed, Sep 3, 2008 at 08:50, Divye Kapoor <div...@gm...> wrote:
>
> On Wed, Sep 3, 2008 at 11:59 AM, Kim Gräsman <kim...@gm...> wrote:
>>
>> Wait... OK, I think I see what's happening:
>>
>> 1) test.xml always contains CRLF, even on Linux
>> 2) On Linux, the Python server serves test.xml with CRLF endings intact
>> 3) If we change test.xml to LF-only, we have worse test coverage for
>> line ending independence
>>
>> Is that it?
>
> That's just it. :-)

Cool, thanks :)

I'm still not happy with having the test fail on Windows due to a
known bug in a third party, but now I understand why converting line
endings on test.xml can be problematic.

I think my main concern is that marking the test as an expected
failure makes it useless--if failure is expected, the only way it can
demonstrate a change in behavior is if Python suddenly starts working.

That said, if we're worried about line endings causing trouble,
shouldn't we have targetted tests for that?

Cheers,
- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Dean,

On Wed, Sep 3, 2008 at 08:44, Dean Michael Berris
<mik...@gm...> wrote:
>
>> I don't see how that's an improvement over saving test.xml with
>> LF-only line endings, and get consistent test results...? I understood
>> Divye's point to be that if we did that, we would mask something else.
>>
>
> It's not about changing the test data to make sure the tests run, it's
> more about making sure we get the correct data that we expect from the
> HTTP Server -- and if I requested for a file that has CRLF line
> endings in from the server, that I would get the exact same file if I
> read it from disk in binary mode.

The thing is, the server you're using cannot serve a file containing
CRLF "for technical reasons" -- wouldn't it seem better to base the
test off a file with LF only?

That way you preserve the premise of the test, but change the details
to compensate for the "technical reasons", so that the test is still
valid.

- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

On Wed, Sep 3, 2008 at 11:59 AM, Kim Gräsman <kim...@gm...> wrote:

> Wait... OK, I think I see what's happening:
>
> 1) test.xml always contains CRLF, even on Linux
> 2) On Linux, the Python server serves test.xml with CRLF endings intact
> 3) If we change test.xml to LF-only, we have worse test coverage for
> line ending independence
>
> Is that it?
>

That's just it. :-)

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] Dispatch Table Example

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

Hi Divye,

On Wed, Sep 3, 2008 at 08:26, Divye Kapoor <div...@gm...> wrote:
>
> Any suggestions for alternative names?

Hmm, that's hard... Some wise man said at one point to name things
after what problem they solve, not after how they do it (paraphrased
:) -- maybe that's a lead...?

 dynamic_methods?
 datadriven_methods?
 method_table?

I don't have any obvious winners :)

- Kim

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Kim,

On Wed, Sep 3, 2008 at 2:29 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Sep 3, 2008 at 07:47, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> 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.
>
> I don't see how that's an improvement over saving test.xml with
> LF-only line endings, and get consistent test results...? I understood
> Divye's point to be that if we did that, we would mask something else.
>

It's not about changing the test data to make sure the tests run, it's
more about making sure we get the correct data that we expect from the
HTTP Server -- and if I requested for a file that has CRLF line
endings in from the server, that I would get the exact same file if I
read it from disk in binary mode.

> Wait... OK, I think I see what's happening:
>
> 1) test.xml always contains CRLF, even on Linux
> 2) On Linux, the Python server serves test.xml with CRLF endings intact
> 3) If we change test.xml to LF-only, we have worse test coverage for
> line ending independence
>
> Is that it?
>

Yes, we want to make sure CRLF is preserved -- and that the file is
intact when sent over the HTTP Server, and received by the client.

>> Perhaps a patch to the test to reflect this would be very welcome. :)
>
> It's included in the patch I sent last night -- in Win32
> configurations the test code strips all CRs from the source text
> document. But maybe a dedicated test would be better to demonstrate
> this.
>

I would like to see though a windows-specific flag which sets the
expected failures to 1 in the localhost_test case that checks for file
lengths.

I haven't taken a look at your patch yet, so I'll see what happens
when I get to it later.

HTH

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

Re: [cpp-netlib-devel] localhost_tests cleanup

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

Hi Kim,

On Wed, Sep 3, 2008 at 2:31 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 tried extracting the ShellExecuteEx and Fork into a separate header file
and creating the fixture but I was continually running into segmentation
faults. So, I put it aside for a while. Thanks for the patch!


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

I think Dean's made a pretty good explanation of what I'm trying to convey.
The file size test that fails on Windows actually passes on Linux because
the linux version of the python library doesn't convert the CRLF to a single
LF. Its a known bug in the Python library that causes the file size mismatch
on windows. Although it helps to keep the tests clean, the text file
transfer test is an expected failure on Windows. It would be better to mark
this test as an expected failure in the test suite rather than making up for
the shortcomings of the Python server.

I hope that clears things up.

Cheers,
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] mime (http integration)

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

On Wed, Sep 3, 2008 at 2:24 PM, Allister Levi Sanchez
<all...@gm...> wrote:
>
> 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)?
>

Oh, right. :D

My bad. :)

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

Yes, Base64 encoding (not yet implemented) will have to go into 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. ;)
>
> Yes, maybe branching off for MIME would be a good idea -- once we've decided
> where to put it hehe...
>

I think you're correct with putting mime into protocol/ -- I imagine
it would need to be split up to multiple files and in its own
directory protocol/mime/ aside from just protocol/mime.hpp ?

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

Re: [cpp-netlib-devel] localhost_tests failures

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

Hi Dean,

On Wed, Sep 3, 2008 at 07:47, Dean Michael Berris
<mik...@gm...> wrote:
>
> 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.

I don't see how that's an improvement over saving test.xml with
LF-only line endings, and get consistent test results...? I understood
Divye's point to be that if we did that, we would mask something else.

Wait... OK, I think I see what's happening:

1) test.xml always contains CRLF, even on Linux
2) On Linux, the Python server serves test.xml with CRLF endings intact
3) If we change test.xml to LF-only, we have worse test coverage for
line ending independence

Is that it?

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

It's included in the patch I sent last night -- in Win32
configurations the test code strips all CRs from the source text
document. But maybe a dedicated test would be better to demonstrate
this.

Thanks,
- Kim

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

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

Hi Kim,

On Wed, Sep 3, 2008 at 1:45 AM, Kim Gräsman <kim...@gm...> wrote:

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

You're absolutely right. Changing the name of the executable removed the
need of the UAC elevation request.
Thanks :-D


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

Any suggestions for alternative names?

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