cpp-netlib-devel

[cpp-netlib-devel] Merging integration_0_4 to trunk; Branching http_server from trunk.

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

In a matter of minutes (after doing the final test run on the merged
trunk I have locally) I will be checking in the merged integration_0_4
branch into trunk. Any further documentation and testing should happen
against the trunk version, so that we can stabilize and tag release
0.4.

To those looking to contribute tests, please do so against the trunk
version after I check in r211 of trunk.

Those looking to contribute in the documentation effort, please do so
against trunk too after I check in r211.

Those interested in helping me integrate a header-only HTTP Server
implementation based on Chris Kholhoff's Boost.Asio HTTP Server 3
example into cpp-netlib (feature requests and patches would be
welcome, for release 0.5), I'll see you in the http_server branch.
More about that later.

Thanks guys and I hope this helps!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Merging integration_0_4 to trunk; Branching http_server from trunk.

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

On Fri, Dec 4, 2009 at 11:48 PM, Dean Michael Berris
<mik...@gm...> wrote:
> In a matter of minutes (after doing the final test run on the merged
> trunk I have locally) I will be checking in the merged integration_0_4
> branch into trunk. Any further documentation and testing should happen
> against the trunk version, so that we can stabilize and tag release
> 0.4.
>

This is done.

All further stabilization should happen on the trunk; I'm branching
off http_server and pushing code there from r211. I shall be re-basing
on a regular basis.

Please let me know if anybody is interested in helping out in this
effort. Thanks in advance and I hope to hear from you guys soon!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Merging integration_0_4 to trunk; Branching http_server from trunk.

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

On Sat, Dec 5, 2009 at 12:11 AM, Dean Michael Berris
<mik...@gm...> wrote:
> On Fri, Dec 4, 2009 at 11:48 PM, Dean Michael Berris
> <mik...@gm...> wrote:
>> In a matter of minutes (after doing the final test run on the merged
>> trunk I have locally) I will be checking in the merged integration_0_4
>> branch into trunk. Any further documentation and testing should happen
>> against the trunk version, so that we can stabilize and tag release
>> 0.4.
>>
>
> This is done.
>
> All further stabilization should happen on the trunk; I'm branching
> off http_server and pushing code there from r211. I shall be re-basing
> on a regular basis.
>

This is done too; r213 now contains the HTTP Server template along
with all required support headers.

There is a test that requires Python 3000 (should we move the Python
implementation of the server to Python 3000 too?) and httplib2 for
Python 3000.

What I would like to get comments on are:

1. Whether we want to support request pipelining on the server side.
2. Whether we want to make it more like a Java framework.
3. Whether we want to unify the request object that the HTTP server
currently uses and the request object that the HTTP client users.
4. What you would like to see in the HTTP Server implementation aside
from full standard HTTP 1.1 support.

Please spread the word and let's get this implementation going!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Merging integration_0_4 to trunk; Branching http_server from trunk.

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

On Fri, Dec 4, 2009 at 21:47, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Dec 5, 2009 at 12:11 AM, Dean Michael Berris
> <mik...@gm...> wrote:
>> On Fri, Dec 4, 2009 at 11:48 PM, Dean Michael Berris
>> <mik...@gm...> wrote:
>>> In a matter of minutes (after doing the final test run on the merged
>>> trunk I have locally) I will be checking in the merged integration_0_4
>>> branch into trunk. Any further documentation and testing should happen
>>> against the trunk version, so that we can stabilize and tag release
>>> 0.4.
>>>
>>
>> This is done.
>>
>> All further stabilization should happen on the trunk; I'm branching
>> off http_server and pushing code there from r211. I shall be re-basing
>> on a regular basis.
>>
>
> This is done too; r213 now contains the HTTP Server template along
> with all required support headers.
>
> There is a test that requires Python 3000 (should we move the Python
> implementation of the server to Python 3000 too?) and httplib2 for
> Python 3000.
>
> What I would like to get comments on are:
>
> 1. Whether we want to support request pipelining on the server side.
> 2. Whether we want to make it more like a Java framework.
> 3. Whether we want to unify the request object that the HTTP server
> currently uses and the request object that the HTTP client users.
> 4. What you would like to see in the HTTP Server implementation aside
> from full standard HTTP 1.1 support.
>
> Please spread the word and let's get this implementation going!
>
> --
> Dean Michael Berris
> blog.cplusplus-soup.com | twitter.com/mikhailberis
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Hi, my two cents on a couple of the above questions,

1. Whether we want to support request pipelining on the server side.
It is certainly a nice feature to have, but on most browsers it is
disabled by default, mostly due to the head of line blocking it
creates, and existing buggy proxy implementations, thus I'd leave it
out for now, it shouldn't be a priority of any kind in my opinion.

> 2. Whether we want to make it more like a Java framework.
I've personally never liked Java that much, but in what way ?

> 3. Whether we want to unify the request object that the HTTP server currently uses and the request object that the HTTP client users.
I've previously used libevent, a library in which this object is
unified, and it has been a pain in writing a wrapper. I would
certainly advise against unifying them from this experience, although
they obviously share quite a bit of common ground. It might be nice to
have a look at http://monkey.org/~provos/libevent/doxygen-2.0.1/http_8h.html,
as they support most of the HTTP 1.1 specification, on how they've
designed their API.

> 4. What you would like to see in the HTTP Server implementation aside from full standard HTTP 1.1 support.
Support for a dispatcher is what comes to mind first of all, thus a
system using which you can registers handlers for URI requests from
the server. I've currently written something trivial of this kind
using boost::startswith, but this can be a lot more general, and
extended to support boost::regex and boost::xpressive for example. As
a sidenote, note that requestst can be an absolute URI in HTTP 1.0,
which you need to strip down to an absolute path for such a dispatcher
for example. Support for virtual hosts could for example also be
achieved using this.

If I come up with more tomorrow, I'll write up a more extensive reply.

Regards,
Jeroen Habraken

Re: [cpp-netlib-devel] Merging integration_0_4 to trunk; Branching http_server from trunk.

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

Hi Jeroen,

On Sat, Dec 5, 2009 at 5:40 AM, Jeroen Habraken <vex...@gm...> wrote:
> On Fri, Dec 4, 2009 at 21:47, Dean Michael Berris
>>
[snip]
>
> Hi, my two cents on a couple of the above questions,
>
> 1. Whether we want to support request pipelining on the server side.
> It is certainly a nice feature to have, but on most browsers it is
> disabled by default, mostly due to the head of line blocking it
> creates, and existing buggy proxy implementations, thus I'd leave it
> out for now, it shouldn't be a priority of any kind in my opinion.
>

Alright. :)

>> 2. Whether we want to make it more like a Java framework.
> I've personally never liked Java that much, but in what way ?
>

Java Container Framework I mis-wrote. I mean something like the Apache
Tomcat container environment where there's a specification of the
interfaces that developers just build upon.

>> 3. Whether we want to unify the request object that the HTTP server currently uses and the request object that the HTTP client users.
> I've previously used libevent, a library in which this object is
> unified, and it has been a pain in writing a wrapper. I would
> certainly advise against unifying them from this experience, although
> they obviously share quite a bit of common ground. It might be nice to
> have a look at http://monkey.org/~provos/libevent/doxygen-2.0.1/http_8h.html,
> as they support most of the HTTP 1.1 specification, on how they've
> designed their API.
>

Right. I've been wrestling with the idea of using a different
namespace or even a different type (which I settled on for the
meantime) for the server request. I guess I'll keep it simple in the
meantime.

FWIW the http::response type is for the client use, while the
http::reply type is for the server use. I don't mind keeping it that
way but the names can get you misled easily.

Anybody else has an idea on how to address this issue?

>> 4. What you would like to see in the HTTP Server implementation aside from full standard HTTP 1.1 support.
> Support for a dispatcher is what comes to mind first of all, thus a
> system using which you can registers handlers for URI requests from
> the server. I've currently written something trivial of this kind
> using boost::startswith, but this can be a lot more general, and
> extended to support boost::regex and boost::xpressive for example. As
> a sidenote, note that requestst can be an absolute URI in HTTP 1.0,
> which you need to strip down to an absolute path for such a dispatcher
> for example. Support for virtual hosts could for example also be
> achieved using this.
>

Sounds like a good idea. A generic or "reference" dispatcher
implementation can be something worth working on. I can envision
something like this:

  http::dispatcher c = list_of(
    make_pair(regex("^/$"), foo()), // foo is a function object type
    make_pair(regex("^/bar$"), bar()) // bar is a function object type
  ); // signatures of foo/bar should support void(request, reply);
  http::server s(c);
  s.run();

Of course a cleaner API would be better too. ;)

> If I come up with more tomorrow, I'll write up a more extensive reply.
>

Thanks Jeroen, I'm looking forward to your more extensive reply.

BTW, have you tried the server implementation yet? I'll try to come up
with a better example than "Hello, World!". :)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com