cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Finished Integrating HTTP Incremental Parser

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

Hi Dean,

On 5 October 2010 19:15, Dean Michael Berris <mik...@gm...> wrote:

> Hey Guys!
>
> Just an update. I'm still looking for a job, so if you've got any C++
> jobs lying around, referrals would be greatly appreciated. I'm already
> talking with a firm now though, but still keeping my options open.
> Hopefully by November I'll go decide on what job to take.
>

I hope your job search is going well.


>
> Anyway, more information in-lined below.
>
> On Wed, Sep 29, 2010 at 5:46 PM, Dean Michael Berris
> <mik...@gm...> wrote:
> >
> >  * The tags system now uses heavy metaprogramming with Boost.MPL.
>
>
Following on from another thread, all these changes from 0.6-0.7 need to be
added to the docs, I think it means that what we have now is out-of-date.


> >  * Make the HTTP 1.0 and HTTP 1.1 tests pass. Right now only the HTTP
> > 1.0 test includes the new asynchronous tags in the build. The HTTP 1.1
> > chunked-encoding transfer is what I intend to work on next, which will
> > also require a new implementation of the incremental parser to support
> > just the chunked-encoding body.
>
> I still don't have the chunked transfer encoding done, and I would
> really like to know if people do rely on chunked transfer encoding
> before I go on working on this implementation. In the meantime the raw
> body is being stored by the client regardless of the transfer
> encoding.
>
> >  * Update and merge the documentation.
>
> I'll work with Glyn on this one.
>
> >  * Implement a callback-based HTTP Client API. The rationale for this
> > is so that instead of returning a response object that has
> > Boost.Thread futures embedded in it (and neatly abstracted away), the
> > client can then just call the appropriate callback(s) for processing
> > headers and the body stream as they become available.
>
> I realize that this requires a worker thread pool implementation which
> has a "life of its own" and lives on different threads that don't deal
> with I/O. This may have to wait as I have to implement this thread
> pool implementation as well.
>
> >  * Implement a streaming HTTP Client API. This means returning a
> > response object that has a stream for a body instead of a pre-built
> > string, as well as taking a request object that has a stream for a
> > body. This should help with file-uploads through PUT/POST to make it
> > not require all the contents of the file be in memory, a shared_ptr<>
> > to a stream should suffice.
> >
>
> Also, this means that the response type may have to change for the
> tags that enable this interface. What has to happen is the response
> objects will contain a shared iostream that's bound to the socket of
> the HTTP request to the server, that starts with the body of the HTTP
> Response Message. This is in the case that the callback would like to
> deal with the response body as a stream. I have an implementation
> somewhere that doesn't expose a stream and holds the contents of the
> response in memory as a string, which should do for most cases that
> the responses aren't huge.
>
> > As of now I don't have access to a MSVC compiler yet -- I'll see if I
> > can get my hands on a Windows machine or VM soon, so that I can
> > continue development on Windows -- but I have been building and
> > testing with Clang and GCC in Linux, against Boost 1.44.0. I need some
> > help in this regard as well as with the identification of issues in
> > case there are any that you come across in the implementation.
> >
>
> Now that the tests build and pass on Linux with GCC and Clang, can
> someone help out with the Windows testing?
>
> Thanks guys and I hope this helps.
>
> PS. Please review the code and let me know if you find any glaring
> bugs or really ugly things that need explanation. That would be
> greatly appreciated. [1]
>

I will make the time to do this.

Thanks,
Glyn

Re: [cpp-netlib-devel] Documentation Push

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

Hi Dean,

On 5 October 2010 20:36, Dean Michael Berris <mik...@gm...> wrote:

> Hi Everyone!
>
> It's that time again nearing the end of a development cycle, and I'm
> pretty much ready to get started on writing/editing documentation.
>
> So far I've updated the README file and turned it from just a simple
> .txt file into an .rst file, which GitHub so graciously formats for
> us. You can find the latest changes in the 0.7-devel branch to get an
> idea here: http://bit.ly/cqtQzX -- to say the least, nicer
> documentation would definitely go a long way IMO.
>
>
If you got my pull request, the latest docs look like this:

http://glynos.github.com/cpp-netlib/

There are a lot of todo stubs, and there is a lot of room for examples.  I
will try and provide some more interesting examples myself, and I'd like to
encourage the cpp-netlib community (such as it is) to come up with cool
stuff.

Glyn

[cpp-netlib-devel] Documentation Push

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

Hi Everyone!

It's that time again nearing the end of a development cycle, and I'm
pretty much ready to get started on writing/editing documentation.

So far I've updated the README file and turned it from just a simple
.txt file into an .rst file, which GitHub so graciously formats for
us. You can find the latest changes in the 0.7-devel branch to get an
idea here: http://bit.ly/cqtQzX -- to say the least, nicer
documentation would definitely go a long way IMO.

Also, if you guys have any time to write up examples on how to use the
HTTP client and the server in concert, I would really like to get some
help in that regard. I have my ideas, but I'd like to hear yours and
see if they're better than mine.

The Twitter client idea might be a little tricky I think especially
now that Twitter has gone OAuth exclusively -- this will require a
developer account and third-party tools for computing the HMAC-SHA1
for the requests.

A SOA example might be useful, but I don't have a lot of ideas as to
what service to build.

Anyway, it's real late on my side of the world so I'll look forward to
your inputs.

Have a good day everyone and I look forward to hearing from you soon!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Finished Integrating HTTP Incremental Parser

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

Hey Guys!

Just an update. I'm still looking for a job, so if you've got any C++
jobs lying around, referrals would be greatly appreciated. I'm already
talking with a firm now though, but still keeping my options open.
Hopefully by November I'll go decide on what job to take.

Anyway, more information in-lined below.

On Wed, Sep 29, 2010 at 5:46 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
>  * The tags system now uses heavy metaprogramming with Boost.MPL.

This is still true, and I highly recommend using clang [0] for your
development on Linux/Mac now.

>  * The tags "http_async_8bit_(udp|tcp)_resolve" are now supported and
> implemented; there should be no changes to client code that wants to
> use the asynchronous (I should say "active") HTTP client
> implementation.
>

It should be noted that the http client and the response objects are a
little heavier now in the asynchronous version. That's because the
client encapsulates a lifetime thread, and the response object
encapsulates futures internally; this uses Boost.Thread
implementations of the thread and the futures.

> There are a number of things that have yet to be done for packaging
> and releasing 0.7-devel:
>
>  * Make the HTTP 1.0 and HTTP 1.1 tests pass. Right now only the HTTP
> 1.0 test includes the new asynchronous tags in the build. The HTTP 1.1
> chunked-encoding transfer is what I intend to work on next, which will
> also require a new implementation of the incremental parser to support
> just the chunked-encoding body.

I still don't have the chunked transfer encoding done, and I would
really like to know if people do rely on chunked transfer encoding
before I go on working on this implementation. In the meantime the raw
body is being stored by the client regardless of the transfer
encoding.

>  * Update and merge the documentation.

I'll work with Glyn on this one.

>  * Implement a callback-based HTTP Client API. The rationale for this
> is so that instead of returning a response object that has
> Boost.Thread futures embedded in it (and neatly abstracted away), the
> client can then just call the appropriate callback(s) for processing
> headers and the body stream as they become available.

I realize that this requires a worker thread pool implementation which
has a "life of its own" and lives on different threads that don't deal
with I/O. This may have to wait as I have to implement this thread
pool implementation as well.

>  * Implement a streaming HTTP Client API. This means returning a
> response object that has a stream for a body instead of a pre-built
> string, as well as taking a request object that has a stream for a
> body. This should help with file-uploads through PUT/POST to make it
> not require all the contents of the file be in memory, a shared_ptr<>
> to a stream should suffice.
>

Also, this means that the response type may have to change for the
tags that enable this interface. What has to happen is the response
objects will contain a shared iostream that's bound to the socket of
the HTTP request to the server, that starts with the body of the HTTP
Response Message. This is in the case that the callback would like to
deal with the response body as a stream. I have an implementation
somewhere that doesn't expose a stream and holds the contents of the
response in memory as a string, which should do for most cases that
the responses aren't huge.

> As of now I don't have access to a MSVC compiler yet -- I'll see if I
> can get my hands on a Windows machine or VM soon, so that I can
> continue development on Windows -- but I have been building and
> testing with Clang and GCC in Linux, against Boost 1.44.0. I need some
> help in this regard as well as with the identification of issues in
> case there are any that you come across in the implementation.
>

Now that the tests build and pass on Linux with GCC and Clang, can
someone help out with the Windows testing?

Thanks guys and I hope this helps.

PS. Please review the code and let me know if you find any glaring
bugs or really ugly things that need explanation. That would be
greatly appreciated. [1]

[0] clang -- http://clang.llvm.org/
[1] 0.7-devel -- http://github.com/mikhailberis/cpp-netlib/tree/0.7-devel

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] Finished Integrating HTTP Incremental Parser

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

Hi Guys!

I just wanted to give a heads up to everyone on the list, and give
everyone an update on what I've been up to so far.

First though, there's been a sudden change in my availability to work
on cpp-netlib. As of yesterday Philippine time I no longer have
anything else to do but to work on cpp-netlib (and find a job on the
side). My consulting engagement had been cut short due to some
unfortunate circumstances. So now until I get a new gig, I'm going to
be dedicating my days working on cpp-netlib (yay! :D).

So here's what's been happening to the library:

  * The tags system now uses heavy metaprogramming with Boost.MPL.
  * The incremental parser now has a stable generic interface and I
intend to lift a concept out of it as soon as I get around to
implementing other incremental parsers for different protocols.
  * There are a number of enhancements in the way the directive system
works, using the Boost.Variant trick that I emailed a couple weeks
ago. That's in 0.7-devel and should make directive making a little
more pleasant with definite extension points to look through.
  * The tags "http_async_8bit_(udp|tcp)_resolve" are now supported and
implemented; there should be no changes to client code that wants to
use the asynchronous (I should say "active") HTTP client
implementation.

There are a number of things that have yet to be done for packaging
and releasing 0.7-devel:

  * Make the HTTP 1.0 and HTTP 1.1 tests pass. Right now only the HTTP
1.0 test includes the new asynchronous tags in the build. The HTTP 1.1
chunked-encoding transfer is what I intend to work on next, which will
also require a new implementation of the incremental parser to support
just the chunked-encoding body.
  * Update and merge the documentation.
  * Implement a callback-based HTTP Client API. The rationale for this
is so that instead of returning a response object that has
Boost.Thread futures embedded in it (and neatly abstracted away), the
client can then just call the appropriate callback(s) for processing
headers and the body stream as they become available.
  * Implement a streaming HTTP Client API. This means returning a
response object that has a stream for a body instead of a pre-built
string, as well as taking a request object that has a stream for a
body. This should help with file-uploads through PUT/POST to make it
not require all the contents of the file be in memory, a shared_ptr<>
to a stream should suffice.

As of now I don't have access to a MSVC compiler yet -- I'll see if I
can get my hands on a Windows machine or VM soon, so that I can
continue development on Windows -- but I have been building and
testing with Clang and GCC in Linux, against Boost 1.44.0. I need some
help in this regard as well as with the identification of issues in
case there are any that you come across in the implementation.

Thanks for reading up to here and let me know if there's anything
immediate that I need to address before I hunker down and finish off
the HTTP client implementation for 0.7.

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

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Incremental Parser Development

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

On Mon, Sep 13, 2010 at 10:56 AM, Dean Michael Berris
<mik...@gm...> wrote:
>
> On Fri, Sep 10, 2010 at 5:30 AM, Jeroen Habraken <vex...@gm...> wrote:
>>
>> Secondly I must ask you to read,
>> and re-read the RFC and to make sure you follow it (I've had a quick
>> glance at the code you've committed and already spotted a deviation,
>> for which I've filed an issue at github).
>>
>
> Yes, thanks. I however would like to deal with the RFC issues later,
> just as soon as I can parse a valid narrow subset of the RFC. My aim
> is really to get something that will allow me to just parse the "known
> good" incoming data in an incremental manner. I will however base test
> inputs on the RFC, so that might allow me to go RFC-compliant in the
> tests, while the implementation might be narrower than the full RFC
> implementation.
>

In this light, I've fixed the issue you filed (#14) with regards to
the HTTP version parsing. I've also finished the incremental parsing
of the status message and headers.

What remains is a body parser that should be able to understand
chunked transfer encoding. I'm not racking my brain with that yet, but
I will be implementing a simplistic incremental parser. This will be
the basis too of a streaming client parser for the responses.

I'm also looking at changing the regex-based implementation of the
existing synchronous client to use this restartable parser and remove
the dependency on Boost.Regex in the near future. Hopefully things
don't break when I introduce the incremental parsing to the
synchronous client implementation. ;)

Have a great one guys and I definitely hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Incremental Parser Development

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

Hi Jeroen!

Sorry about the late response, it was the long weekend here in the
Philippines and I took some time off to have fun with the family. See
some of my thoughts below. :)

On Fri, Sep 10, 2010 at 5:30 AM, Jeroen Habraken <vex...@gm...> wrote:
>
> Hi Dean,
>
> Brilliant! I've personally always considered this to be a weak spot in
> cpp-netlib and given how important it is, I'm glad it's getting some
> attention.

Thanks, it has been in the back of my mind for a while and I think
there's no better way to address it than to actually do something
about it.

> Having said that, I'm surprised you're starting from
> scratch given that there are some very good and tested HTTP parsers
> out there (mongrel comes to mind).

Ah, yes. The rationale is really simple:

1. I'd like it done test-driven, meaning actual requirements dictate
the implementation. This is hard to do if you're going to be basing
the implementation on something already existing. At least this is my
personal view on it.

2. The license might be an issue if I base the implementation on
something existing. Given that cpp-netlib is licensed under the Boost
Software License, anything that is licensed under a non-BSL compatible
license is a non-starter.

3. I'd like to gain more experience writing more parsers by hand to
get a better understanding and get a better chance at optimizing the
implementation at any given point in the future. ;)

So if you can suggest anything that is already Boost Software Licensed
that I can just tweak -- something like what is already in Boost.Asio
examples, which BTW, we already use in the HTTP Server implementation
-- then it might be something I'd be willing to look into. :D

> Secondly I must ask you to read,
> and re-read the RFC and to make sure you follow it (I've had a quick
> glance at the code you've committed and already spotted a deviation,
> for which I've filed an issue at github).
>

Yes, thanks. I however would like to deal with the RFC issues later,
just as soon as I can parse a valid narrow subset of the RFC. My aim
is really to get something that will allow me to just parse the "known
good" incoming data in an incremental manner. I will however base test
inputs on the RFC, so that might allow me to go RFC-compliant in the
tests, while the implementation might be narrower than the full RFC
implementation.

> Currently I've got little time to spend on cpp-netlib since I'm busy
> with a project of my own (shameless plug,
> http://github.com/VeXocide/construe_cast) but I'll definitely be
> following this closely.
>

No worries -- I'm looking forward to construe_cast be proposed and
included in Boost myself ;). I will try to post more about the
progress and discoveries I make along the way.

> Regards,
> Jeroen Habraken
>

Thanks Jeroen and I definitely look forward to more of your insights
as I continue working on this particular part of the library! :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Incremental Parser Development

[Jeroen H. <vex...@gm...>]

On 9 September 2010 19:56, Dean Michael Berris <mik...@gm...> wrote:
> Hi Guys,
>
> Just a quick heads up, I've pushed an incremental parser for HTTP
> responses that I'm building with two birds to hit:
>
> 1. Develop a spec-compliant HTTP response message parser that is
> stateful, space-efficient, and is restartable that will be used in the
> asynchronous http client implementation.
>
> 2. Develop an incremental parser concept which might stand as a good
> abstraction on its own.
>
> #1 is the short term goal, while #2 is the longer term goal. The
> reason for #2 is similar to the reasoning behind the development of
> the Message concept as well as the Request and Response concepts: so
> that it would be easier for us and others to implement compliant,
> drop-in implementations that model the Message, Request, and Response
> concepts. The goal for having a suitable incremental parser interface
> is so that we can generally abstract the client/server implementations
> enough to just rely on concepts like an IncrementalParser which can be
> implemented underneath using as many different technologies as
> possible.
>
> I think if we have an implementation of incremental parsers for HTTP,
> XMPP, SMTP, then that might make a compelling component of the library
> that would be useful in different kinds of applications -- much like
> how the URI parser is really useful in many different contexts outside
> of just cpp-netlib.
>
> Thanks guys and I hope this helps.
>
> PS. In case you want to pick up where I've left things hanging, please
> feel free to fork and send in pull requests. I've tried to document
> the rationale in the test, and will be documenting the rationale for
> the implementation more as I we go along. The test is in
> libs/network/test/http_incremental_parser.cpp (in commit
> http://bit.ly/dmkA9f, the actual file is http://bit.ly/9h61ju). The
> implementation now is able to at least parse the HTTP version part of
> a range, and say whether it was successful or whether there are still
> missing parts, or that the range isn't conforming.
>
> --
> Dean Michael Berris
> deanberris.com
>

Hi Dean,

Brilliant! I've personally always considered this to be a weak spot in
cpp-netlib and given how important it is, I'm glad it's getting some
attention. Having said that, I'm surprised you're starting from
scratch given that there are some very good and tested HTTP parsers
out there (mongrel comes to mind). Secondly I must ask you to read,
and re-read the RFC and to make sure you follow it (I've had a quick
glance at the code you've committed and already spotted a deviation,
for which I've filed an issue at github).

Currently I've got little time to spend on cpp-netlib since I'm busy
with a project of my own (shameless plug,
http://github.com/VeXocide/construe_cast) but I'll definitely be
following this closely.

Regards,
Jeroen Habraken

[cpp-netlib-devel] Incremental Parser Development

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

Hi Guys,

Just a quick heads up, I've pushed an incremental parser for HTTP
responses that I'm building with two birds to hit:

1. Develop a spec-compliant HTTP response message parser that is
stateful, space-efficient, and is restartable that will be used in the
asynchronous http client implementation.

2. Develop an incremental parser concept which might stand as a good
abstraction on its own.

#1 is the short term goal, while #2 is the longer term goal. The
reason for #2 is similar to the reasoning behind the development of
the Message concept as well as the Request and Response concepts: so
that it would be easier for us and others to implement compliant,
drop-in implementations that model the Message, Request, and Response
concepts. The goal for having a suitable incremental parser interface
is so that we can generally abstract the client/server implementations
enough to just rely on concepts like an IncrementalParser which can be
implemented underneath using as many different technologies as
possible.

I think if we have an implementation of incremental parsers for HTTP,
XMPP, SMTP, then that might make a compelling component of the library
that would be useful in different kinds of applications -- much like
how the URI parser is really useful in many different contexts outside
of just cpp-netlib.

Thanks guys and I hope this helps.

PS. In case you want to pick up where I've left things hanging, please
feel free to fork and send in pull requests. I've tried to document
the rationale in the test, and will be documenting the rationale for
the implementation more as I we go along. The test is in
libs/network/test/http_incremental_parser.cpp (in commit
http://bit.ly/dmkA9f, the actual file is http://bit.ly/9h61ju). The
implementation now is able to at least parse the HTTP version part of
a range, and say whether it was successful or whether there are still
missing parts, or that the range isn't conforming.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

On Sat, Sep 4, 2010 at 11:00 AM, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Sep 4, 2010 at 4:16 AM, Divye Kapoor <div...@gm...> wrote:
>> I too can confirm a huge no. of error messages on ubuntu lucid.
>> % g++ --version
>> g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>> ...
>> most of them are indicating lack of << operator implementations. Any ideas
>> on where to start?
>
> I think the header-ordering issue is biting us in the ass now.
>

And *finally* I have the cpp-netlib related tests building in clang.
Somehow the MIME tests are still a little needing attention, and I am
having some hiccups encountered with clang and Boost.MIME -- Marshall,
are you there?

BTW, I just pushed and have the header include issues fixed. So now at
least we can go on stabilizing the branch, and for me to actually
finish the asynchronous client implementation.

Lots for me to do but hopefully I can get a lot of work in this coming week.

Hang in there guys I'll get this futures-based basic_response<> thingy
working soon enough. Once that's done I'm moving on to the server to
support asynchronous handlers and the beginnings of a web framework
that works on top of cpp-netlib.

Fingers crossed I'll have that done by the end of this coming week.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

On Sat, Sep 4, 2010 at 4:16 AM, Divye Kapoor <div...@gm...> wrote:
> I too can confirm a huge no. of error messages on ubuntu lucid.
> % g++ --version
> g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
> ...
> most of them are indicating lack of << operator implementations. Any ideas
> on where to start?

I think the header-ordering issue is biting us in the ass now.

I'm spending quite a lot of time inserting includes and checking the
order of the includes to fix these things. I stopped last night when I
got the hello_world server test building, and now the http_1_0_test is
failing with the overloaded wrapper names are not being properly
resolved by GCC and clang, but MSVC2010 had no problem figuring out.
I'd say it would be better if all the wrappers, modifiers, and
directives were included appropriately. Hopefully that's not too much
work to do and I intend to work on that part in the next few days.

I recommend Divye that you try out clang in Ubuntu to get a better
idea on what the errors really are and some sort of indication on how
to fix them. ;) This has helped me a lot in decoding what the problem
is and what the possible solutions are.

Clang is at http://clang.llvm.org/ -- I can say that it's more
standards-compliant, and whatever build with clang seems to build with
GCC and MSVC, but not the other way around. If we use clang in the
development of things it'd be better because we can have a higher
confidence that it will work in GCC and MSVC.

HTH

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

I too can confirm a huge no. of error messages on ubuntu lucid.
% g++ --version
g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
...

most of them are indicating lack of << operator implementations. Any ideas
on where to start?

---
Thanks,
Divye



On Fri, Sep 3, 2010 at 11:15 PM, Dean Michael Berris <mik...@gm...
> wrote:

> On Fri, Sep 3, 2010 at 12:06 PM, Dean Michael Berris
> <mik...@gm...> wrote:
> >
> > Ah, right. I haven't considered that -- no tests cover the uri
> > directive at this time (except for the concept checks). MSVC 2010
> > doesn't complain about the URI function and the URI type having the
> > same name though, so I can't say what the fix should be. I'll try
> > building it in my Ubuntu desktop to see if I can make it build
> > correctly with GCC soon.
> >
> > It would be great if you can send me a pull request so that I can test
> > on Windows with MSVC 2010 as well on my repo.
> >
>
> I tried working with clang and I can say that it's way better in
> pointing out errors. And it's also lightning fast compared to GCC --
> it compiles everything in 30% less time. I highly recommend developing
> with clang instead of GCC on Linux -- even for just the error
> messages.
>
> I'm going to keep whacking at this as I go along, so please expect
> things to be in a flux on the 0.7-devel branch.
>
> Sorry about the breakage, but some of the refactorings were a little
> hairy and is getting very involved. At some point a real cleanup of
> the implementation has to be done (by me).
>
> Help would most definitely be appreciated.
>
> Have a great weekend guys!
>
> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

On Fri, Sep 3, 2010 at 12:06 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> Ah, right. I haven't considered that -- no tests cover the uri
> directive at this time (except for the concept checks). MSVC 2010
> doesn't complain about the URI function and the URI type having the
> same name though, so I can't say what the fix should be. I'll try
> building it in my Ubuntu desktop to see if I can make it build
> correctly with GCC soon.
>
> It would be great if you can send me a pull request so that I can test
> on Windows with MSVC 2010 as well on my repo.
>

I tried working with clang and I can say that it's way better in
pointing out errors. And it's also lightning fast compared to GCC --
it compiles everything in 30% less time. I highly recommend developing
with clang instead of GCC on Linux -- even for just the error
messages.

I'm going to keep whacking at this as I go along, so please expect
things to be in a flux on the 0.7-devel branch.

Sorry about the breakage, but some of the refactorings were a little
hairy and is getting very involved. At some point a real cleanup of
the implementation has to be done (by me).

Help would most definitely be appreciated.

Have a great weekend guys!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

On Fri, Sep 3, 2010 at 5:38 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean.
> Its great to hear you're making progress.
>

I'm just happy I get to do C++ now. :D

> On 2 September 2010 19:06, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> Hi Guys,
>>
>> I've got some good news and some better news.
>>
>> The good news is that the current 0.7-devel branch after the
>> introduction of the asynchronous HTTP connection stuff and the HTTP
>> Request/Response and enhanced Message concepts, is now stable enough
>> to continue working on. I intend to push more work in progress code so
>> if you're interested in helping out with the asynchronous connection
>> implementation, now is a good time to jump in.
>>
>> The better news is that I just got the green light to work on
>> cpp-netlib while I'm in between projects. So hopefully you'll see more
>> progress from me in the next couple of weeks.
>>
>> That's all for now and hopefully everyone can start helping with
>> testing the bug fixes and the CMake build in Windows/Linux on
>> different compilers now.
>>
>
> I tried to build using GCC 4.4.3 on Ubuntu and I get tons and tons of
> errors.  Most of them it appears to be simply missing headers or misplaced
> typenames.  I got so far but couldn't continue because
> boost::network::http::uri is being defined in more than place
> (boost/network/protocol/http/message/directives/uri.hpp and
> boost/network/uri/http/uri.hpp).  I committed my changes in the 0.7-devel
> branch of my own repository.

Ah, right. I haven't considered that -- no tests cover the uri
directive at this time (except for the concept checks). MSVC 2010
doesn't complain about the URI function and the URI type having the
same name though, so I can't say what the fix should be. I'll try
building it in my Ubuntu desktop to see if I can make it build
correctly with GCC soon.

It would be great if you can send me a pull request so that I can test
on Windows with MSVC 2010 as well on my repo.

>>
>>
>> Have a good one guys and I hope this helps!
>>
>
> G
>

Thanks Glyn!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Stabilizing 0.7-devel

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

Hi Dean.

Its great to hear you're making progress.

On 2 September 2010 19:06, Dean Michael Berris <mik...@gm...>wrote:

> Hi Guys,
>
> I've got some good news and some better news.
>
> The good news is that the current 0.7-devel branch after the
> introduction of the asynchronous HTTP connection stuff and the HTTP
> Request/Response and enhanced Message concepts, is now stable enough
> to continue working on. I intend to push more work in progress code so
> if you're interested in helping out with the asynchronous connection
> implementation, now is a good time to jump in.
>
> The better news is that I just got the green light to work on
> cpp-netlib while I'm in between projects. So hopefully you'll see more
> progress from me in the next couple of weeks.


> That's all for now and hopefully everyone can start helping with
> testing the bug fixes and the CMake build in Windows/Linux on
> different compilers now.
>
>
I tried to build using GCC 4.4.3 on Ubuntu and I get tons and tons of
errors.  Most of them it appears to be simply missing headers or misplaced
typenames.  I got so far but couldn't continue because
boost::network::http::uri is being defined in more than place
(boost/network/protocol/http/message/directives/uri.hpp and
boost/network/uri/http/uri.hpp).  I committed my changes in the 0.7-devel
branch of my own repository.


> Have a good one guys and I hope this helps!
>
>
G

[cpp-netlib-devel] Stabilizing 0.7-devel

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

Hi Guys,

I've got some good news and some better news.

The good news is that the current 0.7-devel branch after the
introduction of the asynchronous HTTP connection stuff and the HTTP
Request/Response and enhanced Message concepts, is now stable enough
to continue working on. I intend to push more work in progress code so
if you're interested in helping out with the asynchronous connection
implementation, now is a good time to jump in.

The better news is that I just got the green light to work on
cpp-netlib while I'm in between projects. So hopefully you'll see more
progress from me in the next couple of weeks.

That's all for now and hopefully everyone can start helping with
testing the bug fixes and the CMake build in Windows/Linux on
different compilers now.

Have a good one guys and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

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

On Fri, Aug 27, 2010 at 5:13 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> And now at least the thing builds. I'll just have to much around with
> the linking and CMake on windows, but it should be usable in the next
> push I do which should be within the day (my day).
>
> Fingers crossed...
>

I've pushed to the 0.7-devel branch a huge thunk of changes. I'm
afraid this branch is so unstable that it's going to take a while
before I can get something remotely release-ready anytime soon.

The problem I'm facing right now is in the ensuring that the concepts
are met -- which is going to be crucial if we intend to let users and
others build message types that deal with CString, QString, and other
string implementations.

Hopefully the message concept gets pinned down soon. I'm going to take
on this personally so that we can get a move on in other more
important things like the HTTP server and the middleware that allows
for streaming input and streaming output from the handlers.
Asynchronous writes and reads on the handler level would also be
welcomed by a lot of people.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

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

On Tue, Aug 24, 2010 at 6:33 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> And you might have to wait a little longer. Now the problem I'm
> reaching is the consequence of the Request concept applying to both
> asynchronous and synchronous request objects. The Request concept
> refines the Message concept, which defines some primitive operations
> to be defined.
>
> Now I've added modifiers to the requirement on the Message concept,
> which means creating messages just got a little "harder" and more
> involved.
>
> Maybe at some point I'm just going to make a Directive concept too.
>
> I'm learning that generic programming is a little more involved (but
> really safe) and thus fun to implement. ;)
>

And now at least the thing builds. I'll just have to much around with
the linking and CMake on windows, but it should be usable in the next
push I do which should be within the day (my day).

Fingers crossed...

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

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

On Sat, Aug 21, 2010 at 5:22 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 20 August 2010 12:03, Dean Michael Berris <mik...@gm...> wrote:
>>
>> I found one good hack to make the directives more generic and more
>> tied into the async-friendly messages. I've implemented it locally and
>> am in the process of gutting every directive we've ever written (I
>> really need to learn preprocessor metaprogramming at some point to
>> make this easier).
>>
>
> Cool, this is what I need because I'm a little blocked.  Let me know when
> you have something that I can play with and I'll take a look.

And you might have to wait a little longer. Now the problem I'm
reaching is the consequence of the Request concept applying to both
asynchronous and synchronous request objects. The Request concept
refines the Message concept, which defines some primitive operations
to be defined.

Now I've added modifiers to the requirement on the Message concept,
which means creating messages just got a little "harder" and more
involved.

Maybe at some point I'm just going to make a Directive concept too.

I'm learning that generic programming is a little more involved (but
really safe) and thus fun to implement. ;)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

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

Hi Dean,

On 20 August 2010 12:03, Dean Michael Berris <mik...@gm...> wrote:

> I found one good hack to make the directives more generic and more
> tied into the async-friendly messages. I've implemented it locally and
> am in the process of gutting every directive we've ever written (I
> really need to learn preprocessor metaprogramming at some point to
> make this easier).
>
>
Cool, this is what I need because I'm a little blocked.  Let me know when
you have something that I can play with and I'll take a look.
G

[cpp-netlib-devel] Eureka! Boost.Variant to the rescue for directives

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

I found one good hack to make the directives more generic and more
tied into the async-friendly messages. I've implemented it locally and
am in the process of gutting every directive we've ever written (I
really need to learn preprocessor metaprogramming at some point to
make this easier).

The basic pattern is this:

struct directive {
  boost::variant<
    string<tags::default_string>::type,
    string<tags::default_wstring>::type,
    boost::shared_future<string<tags::default_string>::type>,
    boost::shared_future<string<tags::default_wstring>::type>
  > value_;

  directive(string<tags::default_string>::type const & value)
    : value_(value) {}
  directive(string<tags::default_wstring>::type const & value)
    : value_(value) {}
  directive(boost::shared_future<string<tags::default_string>::type>
const & value)
    : value_(value) {}
  directive(boost::shared_future<string<tags::default_wstring>::type>
const & value)
    : value_(value) {}

  template <class Tag>
  struct value :
    mpl::if_<
      is_async<Tag>,
      boost::shared_future<typename string<Tag>::type>,
      typename mpl::if_<
        is_sync<Tag>,
        typename string<Tag>::type,
        unsupported_tag<Tag>
      >::type
    >
  {};

  template <class Tag, class Message>
  struct value_visitor : boost::static_visitor<> {
    Message const & message_;
    value_visitor(Message const & message)
      : message_(message) {}
    void operator() (typename value<Tag>::type const & value) const {
      message_.value(value);
    }
    template <class T> void operator() (T const &) const {
      // FIXME -- fail here somehow at compile time
    }
  };

  template <class Message>
  Message & operator() (Message const & message) const {
    apply_visitor(value_visitor<typename Message::tag,
Message>(message), value_);
    return message;
  }
};

So yeah, the idea is metaprogramming technically saves the day... :)

Expect a few changes (well, technically a lot of changes ;) ) to come
into the branch.

Have a good one guys, and it's good to be programming C++ again. :D

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] How to get remote IP when handlinghttprequest?

[Paolo F. <pfa...@fr...>]

2010/8/5 Александр Мартынов <am...@ma...>:
>
> Thu, 5 Aug 2010 19:08:13 +0800 письмо от Dean Michael Berris <mik...@gm...>:
>
>>
>> Please don't top post.
> Ok, sorry!
>
>>
>> You should be able to get the function via ADL if you included the
>> correct headers. There are a number of places where the source
>> function is defined, for network messages in general.
>
> I can't understand what do you mean ;( What is the ADL is?

ADL = argument dependent lookup. It's how C++ looks up what actual
function to use if the code has an unqualified function based on its
parameters.

-- 
Paolo Alexis Falcone

Cell: 63-917-508-4702
SIP: 1-747-467-6906
GTalk: pfalcone
YM: p.falcone
Skype: pfalcone
Gizmo5: paolo_falcone

Re: [cpp-netlib-devel] How to get remote IP when handlinghttprequest?

[Александр М. <am...@ma...>]

Thu, 5 Aug 2010 19:08:13 +0800 письмо от Dean Michael Berris <mik...@gm...>:

> 
> Please don't top post.
Ok, sorry!

> 
> You should be able to get the function via ADL if you included the
> correct headers. There are a number of places where the source
> function is defined, for network messages in general.

I can't understand what do you mean ;( What is the ADL is?

Alex Martynov

Re: [cpp-netlib-devel] How to get remote IP when handling httprequest?

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

2010/8/5 Александр Мартынов <am...@ma...>:
> In which namespace/file I can find "source" function?
> I try to find in v0.5. Is there any problems when upgrading from 0.5 to 0.6? Is there no/little changes needed in my code to work with v0.6?
>

Please don't top post.

You should be able to get the function via ADL if you included the
correct headers. There are a number of places where the source
function is defined, for network messages in general.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] How to get remote IP when handling httprequest?

[Александр М. <am...@ma...>]

In which namespace/file I can find "source" function?
I try to find in v0.5. Is there any problems when upgrading from 0.5 to 0.6? Is there no/little changes needed in my code to work with v0.6?

> > Hello,
> >
> >  I'm using cpp-netlib v0.5 in my http server and I want to get remote
> >  (peer) IP-address when I handle request. How I can get it?
> >
> 
> You can check the source of the request object that gets passed into
> the handler. You can do this by doing:
> 
>     string ip = source(request);
> 
> If this doesn't work then that should be a bug. :)
> 
> HTH
> 
> (BTW, you might want to use 0.6 instead of 0.5).
> 
> -- 
> Dean Michael Berris
> deanberris.com
> 

Alex Martynov