Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Jeroen H. <vex...@gm...> - 2009-12-14 12:35:44
|
On Mon, Dec 14, 2009 at 13:03, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen, > > On Mon, Dec 14, 2009 at 5:42 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote: > [snip] >> >> I'm currently working on URI, and the HTTP part in specific, trying to >> make it more strict, RFC compliant. The query and fragments should be >> working now, the path is still a bit of a pain. I'll keep you up to >> date, and expect a patch sometime soon :) >> > > Cool, please either fork the library on Github or send a git patch > later on. I will be freezing the Subversion repository tomorrow. I'm currently working with version 0.4 as a base, but I should indeed switch to trunk. > > Have a good day! > > -- > Dean Michael Berris > blog.cplusplus-soup.com | twitter.com/mikhailberis > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2009-12-14 12:04:57
|
Hi Jeroen, On Mon, Dec 14, 2009 at 5:42 PM, Jeroen Habraken <vex...@gm...> wrote: > On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote: [snip] > > I'm currently working on URI, and the HTTP part in specific, trying to > make it more strict, RFC compliant. The query and fragments should be > working now, the path is still a bit of a pain. I'll keep you up to > date, and expect a patch sometime soon :) > Cool, please either fork the library on Github or send a git patch later on. I will be freezing the Subversion repository tomorrow. Have a good day! -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-12-14 09:46:03
|
Hi Jeroen, 2009/12/14 Jeroen Habraken <vex...@gm...> > > Hi, > > I'm currently working on URI, and the HTTP part in specific, trying to > make it more strict, RFC compliant. The query and fragments should be > working now, the path is still a bit of a pain. I'll keep you up to > date, and expect a patch sometime soon :) > > Thanks for doing this and keeping us up to date. Glyn |
|
From: Jeroen H. <vex...@gm...> - 2009-12-14 09:42:51
|
On Mon, Dec 14, 2009 at 10:20, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > 2009/12/14 Dean Michael Berris <mik...@gm...> >> >> Next I'll be working on the connection management policy that >> dispatches based on the HTTP versions and the tag parameter. The >> connection management policy will look like the following: >> >> HTTP Version | Tag | Behavior >> HTTP 1.1 | http_default_8bit_*_resolver | All requests default to >> 'Connection: close", one request one connection. >> HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host, >> connections are persistent and re-usable, unless server sends >> 'Connection: close' to a response. >> HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active >> object, results are future<basic_response<Tag> >, one request one >> connection. >> HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes >> active object, results are future<basic_response<Tag> >, connections >> are pooled 2 per host. >> HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active >> object, requests will have a function object parameter which handles >> streaming data, one connection per request. >> HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes >> active, requests will have a function object parameter which handles >> streaming data, connections are pooled 2 per host. >> > > This is difficult to read in my e-mail program. In any case, I think this > belongs on the wiki. It would be useful to provide a catalogue of all tags > on the wiki and eventually in the quickbook docs. > >> >> Questions, comments, suggestions, and contributions would be very much >> welcome. >> > > `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp` > (where it can therefore be documented in quickbook). I think that's a > really nice example, an HTTP server in C++ in less than 40 lines ;) Though > the `request_header` type is either a struct or it's using a C++0x > initializer list. > > G > Hi, I'm currently working on URI, and the HTTP part in specific, trying to make it more strict, RFC compliant. The query and fragments should be working now, the path is still a bit of a pain. I'll keep you up to date, and expect a patch sometime soon :) Jeroen |
|
From: Glyn M. <gly...@gm...> - 2009-12-14 09:20:14
|
Hi Dean, 2009/12/14 Dean Michael Berris <mik...@gm...> > > Next I'll be working on the connection management policy that > dispatches based on the HTTP versions and the tag parameter. The > connection management policy will look like the following: > > HTTP Version | Tag | Behavior > HTTP 1.1 | http_default_8bit_*_resolver | All requests default to > 'Connection: close", one request one connection. > HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host, > connections are persistent and re-usable, unless server sends > 'Connection: close' to a response. > HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active > object, results are future<basic_response<Tag> >, one request one > connection. > HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes > active object, results are future<basic_response<Tag> >, connections > are pooled 2 per host. > HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active > object, requests will have a function object parameter which handles > streaming data, one connection per request. > HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes > active, requests will have a function object parameter which handles > streaming data, connections are pooled 2 per host. > > This is difficult to read in my e-mail program. In any case, I think this belongs on the wiki. It would be useful to provide a catalogue of all tags on the wiki and eventually in the quickbook docs. > Questions, comments, suggestions, and contributions would be very much > welcome. > > `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp` (where it can therefore be documented in quickbook). I think that's a really nice example, an HTTP server in C++ in less than 40 lines ;) Though the `request_header` type is either a struct or it's using a C++0x initializer list. G |
|
From: Dean M. B. <mik...@gm...> - 2009-12-14 02:11:29
|
Hi Everyone, So recently I've finished moving the code from Subversion to Git and also continuing development on Github. I've made a branch 0.5-devel in the Git repository on Github and here's what I've been doing so far. I've been making some steady progress with supporting HTTP 1.1 by first refactoring the current client implementation. In the 0.5-devel branch I've renamed tags::http to tags::http_8bit_tcp_resolver (which is the default typedef for http::client). I've created another tag 'tags::http_8bit_udp_resolver' which, when used with the http::basic_client as the tag template parameter will actually use a UDP resolver. There's also a new trait dispatcher to determine the resolver policy as well as the type of the resolver to use based on the tag provided. Next I'll be working on the connection management policy that dispatches based on the HTTP versions and the tag parameter. The connection management policy will look like the following: HTTP Version | Tag | Behavior HTTP 1.1 | http_default_8bit_*_resolver | All requests default to 'Connection: close", one request one connection. HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host, connections are persistent and re-usable, unless server sends 'Connection: close' to a response. HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active object, results are future<basic_response<Tag> >, one request one connection. HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes active object, results are future<basic_response<Tag> >, connections are pooled 2 per host. HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active object, requests will have a function object parameter which handles streaming data, one connection per request. HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes active, requests will have a function object parameter which handles streaming data, connections are pooled 2 per host. In the process, I will be supporting HTTPS as a protocol in the connection objects, using dynamic polymorphism to differentiate between the normal TCP connections and HTTPS connections. Questions, comments, suggestions, and contributions would be very much welcome. Thanks in advance 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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-13 15:36:57
|
On Sun, Dec 13, 2009 at 11:04 PM, Dean Michael Berris <mik...@gm...> wrote: [snip] > > More about this later. > I've imported the repository to github now too, please see http://github.com/mikhailberis/cpp-netlib -- I'm adding people who already have accounts in Github that were part of the original developers of the library as collaborators. If you don't already have a github account and have commit access to the subversion repository, please create one so that I can add you as a collaborator. If you feel like forking the code instead then it should be easier to do that with github -- which is actually also encouraged. Thanks everyone -- if you have any questions please let me know so that I can address them sooner than later. Have a good day 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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-13 15:04:55
|
Good day everyone, I'm moving a little quicker than usual in this case. I'm spending a couple hours to move the repository to github. I'll send another update. I've merged the http-server branch too, and added support for CMake builds alongside Boost.Build. More about this later. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-12-10 10:17:50
|
Hi, Version 0.4 is now available from sourceforge. It includes: A URI Updated documentation and tests. The next stage has been outlined by Dean in his last post to the list. This includes: First, a migration to GitHub Then by the end of January the HTTP 1.1 client and HTTP server. I don't know at this stage if I'll continue to do the point releases in the same way when we move to Git, I don't feel it's very effective because development is going to be more distributed and more rapid. It could be some time before the project is really stable, and it might be more effective if users simply downloaded the latest repository version. Does anyone have comments on this procedure? Thanks to everyone who has contributed, Glyn |
|
From: Dean M. B. <mik...@gm...> - 2009-12-09 13:58:33
|
On Wed, Dec 9, 2009 at 4:30 AM, Glyn Matthews <gly...@gm...> wrote: > > 2009/12/8 Dean Michael Berris <mik...@gm...> >> >> December 16, 2009 >> * Freeze the Subversion tree >> * Import the Subversion tree to Github >> * All further development will be done on Github, mailing lists and >> release management stays in Sourceforge >> * Issues are migrated from Trac to Github Issues, and Wiki Pages >> will be migrated to Github too > > I understood we were moving to Git, but we're moving completely away from > sourceforge? Why is this? I already have an account on Github, but I can't > say I'm familiar with it yet. > The easy "forking" nature available in Github as well as a spiffier interface allows for better development on a per-contributor basis. The limiting nature of a single subversion repository causes the same problem that the Boost single subversion repository brings in. I don't think there's anything similar with Sourceforge and that's the only reason I want to move to Github. >> >> December 24, 2009 >> * Branch for 0.5 which will include: >> - HTTPS support >> - HTTP Server >> > > For most of this I think you'll be working on your own, so the schedule is > down to you. I will be completely away until the middle of January. > I actually think the branching for 0.5 should happen earlier, but I was thinking maybe bug reports will need to be addressed for 0.4 before we branch for 0.5. >> >> January 30, 2009 >> * Release 0.5 >> > > You're the only one who knows if this is a reliable target. I will be very > interested in seeing progress. > Alright. :) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-12-08 20:30:33
|
Hi, 2009/12/8 Dean Michael Berris <mik...@gm...> > Good day everyone, > > I would like to move the development of the cpp-netlib project from > Subversion to Git. Please see my plan below and let me know if there > are any objections to the plan: > > December 10, 2009 > * Release version 0.4 with updated documentation after a final > release testing on multiple platforms. > > No objection here, I'm happy releasing on Thursday. > December 15, 2009 > * Merge the http-server branch into trunk with no failing tests. > > December 16, 2009 > * Freeze the Subversion tree > * Import the Subversion tree to Github > * All further development will be done on Github, mailing lists and > release management stays in Sourceforge > * Issues are migrated from Trac to Github Issues, and Wiki Pages > will be migrated to Github too > I understood we were moving to Git, but we're moving completely away from sourceforge? Why is this? I already have an account on Github, but I can't say I'm familiar with it yet. > > December 24, 2009 > * Branch for 0.5 which will include: > - HTTPS support > - HTTP Server > > For most of this I think you'll be working on your own, so the schedule is down to you. I will be completely away until the middle of January. > January 30, 2009 > * Release 0.5 > > You're the only one who knows if this is a reliable target. I will be very interested in seeing progress. Thanks, Glyn |
|
From: Dean M. B. <mik...@gm...> - 2009-12-08 15:35:17
|
Good day everyone,
I would like to move the development of the cpp-netlib project from
Subversion to Git. Please see my plan below and let me know if there
are any objections to the plan:
December 10, 2009
* Release version 0.4 with updated documentation after a final
release testing on multiple platforms.
December 15, 2009
* Merge the http-server branch into trunk with no failing tests.
December 16, 2009
* Freeze the Subversion tree
* Import the Subversion tree to Github
* All further development will be done on Github, mailing lists and
release management stays in Sourceforge
* Issues are migrated from Trac to Github Issues, and Wiki Pages
will be migrated to Github too
December 24, 2009
* Branch for 0.5 which will include:
- HTTPS support
- HTTP Server
January 30, 2009
* Release 0.5
If there are any suggestions and questions/comments please let me know
as soon as possible. Thanks in advance 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
|
|
From: Dean M. B. <mik...@gm...> - 2009-12-05 16:46:54
|
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 |
|
From: Jeroen H. <vex...@gm...> - 2009-12-04 21:41:16
|
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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-04 20:47:16
|
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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-04 16:12:06
|
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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-04 15:48:39
|
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 |
|
From: Dean M. B. <mik...@gm...> - 2009-12-01 15:06:37
|
Glyn! On Tue, Dec 1, 2009 at 5:12 AM, Glyn Matthews <gly...@gm...> wrote: > Dean, > > > I have some comments: > > Your URI tests indicate that you have a function "protocol". In the > implementation, you refer to "scheme". Shouldn't "protocol" be named > "scheme"? Yes, my bad. scheme and protocol can both be put there. Let me fix that, unless you already have that done. :D > I added a couple of extra tests for the URI, but they're not the negative > ones you were looking for ;) No worries, more tests for more situations in my book would be better. :) > There is a failing test in > localhost_tests.cpp, I think the file server/test.xml has different line > endings, meaning that the content-length value is different. Yeah, we really have to adopt some convention similar to the Boost guidelines about subversion. Or when we move to Git we can configure that better. ;) > Also, I added a very simple example, a wget clone that uses URI and > http::client. It works, but it does show up a couple of problems with the > way the uri and client aren't well integrated. Yup, I think it means we'll need overloads or just plain replace the interface of the client methods that take an http::uri as a parameter instead of just a string. > > I'll continue to make piecemeal updates as and when I can. > Sweet, thanks for the update Glyn! -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-11-30 21:12:30
|
Dean, I have some comments: Your URI tests indicate that you have a function "protocol". In the implementation, you refer to "scheme". Shouldn't "protocol" be named "scheme"? I added a couple of extra tests for the URI, but they're not the negative ones you were looking for ;) There is a failing test in localhost_tests.cpp, I think the file server/test.xml has different line endings, meaning that the content-length value is different. Also, I added a very simple example, a wget clone that uses URI and http::client. It works, but it does show up a couple of problems with the way the uri and client aren't well integrated. I'll continue to make piecemeal updates as and when I can. Glyn |
|
From: Dean M. B. <mik...@gm...> - 2009-11-30 16:42:42
|
On Mon, Nov 30, 2009 at 11:17 PM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > 2009/11/30 Dean Michael Berris <mik...@gm...> >> >> I'll work on these throughout the week. >> >> I hope this helps! > > Yes it does! > > If there's anything you need me to do (even to clarify the docs I've already > written), please let me know. Will do. Thanks. :) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2009-11-30 15:17:53
|
Hi Dean, 2009/11/30 Dean Michael Berris <mik...@gm...> > On Mon, Nov 30, 2009 at 7:11 AM, Dean Michael Berris > <mik...@gm...> wrote: > > On Mon, Nov 30, 2009 at 4:30 AM, Glyn Matthews <gly...@gm...> > wrote: > >> > >> 2009/11/29 Dean Michael Berris <mik...@gm...> > >>> > >>> Do you remember the other checklist items? > >>> > >> > >> There are 8 open tickets, otherwise: > >> > >> 1. URI > > > > I think I need to merge in your changes from the integration_0_4 > > branch into my branch -- apparently you've fixed the string specific > > stuff and I haven't picked those up yet. :D > > > > Actually I fixed a few more things too before committing the merge. I > will now abandon the urllib-dean branch. I've merged my changes from > my branch and added some fixes following your lead on integration_0_4. > > >> 2. HTTP URI in client > > > > The merge would have to wait then for the merge I need to do from above. > > > > Which is already done as well. :) > > >> 3. Better docs > >> 4. Better examples > >> > >> We're doing quite poorly for docs and examples. > >> > > > > Yeah, let me see what I can do about those. > > > > I'll work on these throughout the week. > > I hope this helps! > Yes it does! If there's anything you need me to do (even to clarify the docs I've already written), please let me know. G |
|
From: Dean M. B. <mik...@gm...> - 2009-11-30 14:41:26
|
On Mon, Nov 30, 2009 at 7:11 AM, Dean Michael Berris <mik...@gm...> wrote: > On Mon, Nov 30, 2009 at 4:30 AM, Glyn Matthews <gly...@gm...> wrote: >> >> 2009/11/29 Dean Michael Berris <mik...@gm...> >>> >>> Do you remember the other checklist items? >>> >> >> There are 8 open tickets, otherwise: >> >> 1. URI > > I think I need to merge in your changes from the integration_0_4 > branch into my branch -- apparently you've fixed the string specific > stuff and I haven't picked those up yet. :D > Actually I fixed a few more things too before committing the merge. I will now abandon the urllib-dean branch. I've merged my changes from my branch and added some fixes following your lead on integration_0_4. >> 2. HTTP URI in client > > The merge would have to wait then for the merge I need to do from above. > Which is already done as well. :) >> 3. Better docs >> 4. Better examples >> >> We're doing quite poorly for docs and examples. >> > > Yeah, let me see what I can do about those. > I'll work on these throughout the week. I hope this helps! -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2009-11-29 23:11:26
|
On Mon, Nov 30, 2009 at 4:30 AM, Glyn Matthews <gly...@gm...> wrote: > > 2009/11/29 Dean Michael Berris <mik...@gm...> >> >> Do you remember the other checklist items? >> > > There are 8 open tickets, otherwise: > > 1. URI I think I need to merge in your changes from the integration_0_4 branch into my branch -- apparently you've fixed the string specific stuff and I haven't picked those up yet. :D > 2. HTTP URI in client The merge would have to wait then for the merge I need to do from above. > 3. Better docs > 4. Better examples > > We're doing quite poorly for docs and examples. > Yeah, let me see what I can do about those. > >> >> The only thing I remember are: uri implementation and https (?). Am I >> missing anything else? >> > > How close are you to HTTPS? If it can't be done soon then I suggest we get > a release before returning to this later. Nowhere near. Yup, we should move HTTPS to 0.5. I want to stabilize the URI implementation first. Thanks for the response! :) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2009-11-29 22:00:27
|
Hi Glyn, On Mon, Nov 30, 2009 at 4:27 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > 2009/11/29 Dean Michael Berris <mik...@gm...> >> >> Hi Guys, >> >> I'm doing some consulting work right now which allowed me to implement >> an HTTP Server template which thankfully I've gotten a go-signal to >> opensource under the Boost Software License. > > Cool. > Indeed. :) >> This is not the same HTTP server template that I developed in >> Friendster -- I'm still waiting for them to release that as open >> source -- and this implementation heavily borrows from the Boost.Asio >> server 3 example (although is header only). > > Are these two different implementations of the same thing or do you intend > to do some merge on the differences? I'm looking forward to seeing this. > They're almost the same, although the version I'm releasing in a few hours is a little more simplistic in its implementation than the Friendster version. I'm going to be following up on that version with some of my friends in Friendster, hopefuly they can get to it sooner than later. In the meantime I'd love to get help evolving the implementation to a point where it's ready for "full featured production use". >> >> Glyn, how are we doing with releasing version 0.4? I'll request a >> merge from my urllib-dean branch into integration_0_4 so that we can >> finally merge back to trunk and release version 0.4 that uses >> Boost.Spirit 2.1. > > Please feel free to do the merge. John sent me a off list saying that he > didn't want to contribute any longer and, since his branch has diverged a > long way, I don't expect we'll be able to reintegrate it. > That's a shame. I really hope he would consider contributing at a later date following the conventions and techniques being used in the implementation now. > For 0.4 I wanted: > > A URI package with unit tests I think we have this now although the tests are not enough yet. > The HTTP client using the new URI (which you say you just completed) Yup. :) > Better docs I can try helping out in this regard since I like writing a lot anyway. ;) > Better examples I'll see if I can come up with more of these. > > I would therefore say we're pretty close, short of the documentation. I'm > afraid I can only commit a small amount of time in the next couple of weeks, > but I will try and make progress with the documentation so as not to hold up > the release. (Also, please feel free to pass comment on the current docs in > integration_0_4). > No pressure, and thanks for letting us know of your availability. Maybe someone else can help out in the documentation effort? > I take a holiday on the 17th Dec so I expect to release before then. Alright, I'm gunning for a Dec. 10 paper to be submitted for BoostCon and a presentation on the various techniques used in the library. In particular I'm looking at the following: * Tag-based header-only delineation and implementation (one of the more misunderstood techniques of the library) * Directive-based DSEL for message building * Fluent interface for protocol interfaces I intend to share progress on the paper to both the Boost Developers mailing list and our mailing list as I go along in writing the paper. I'm thinking of using Google Docs for that effort too. Thanks 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 |
|
From: Glyn M. <gly...@gm...> - 2009-11-29 20:30:36
|
2009/11/29 Dean Michael Berris <mik...@gm...> > On Mon, Nov 30, 2009 at 4:14 AM, Glyn Matthews <gly...@gm...> > wrote: > > Hi Dean, > > > > 2009/11/29 Dean Michael Berris <mik...@gm...> > >> > >> Hi Guys, > >> > >> I've just committed revision 203 which integrates the URI > >> implementation into http::request. Now the classic spirit parser in > >> http::request has been removed and delegated to the URI object > >> internal to every http::request. > >> > >> All tests pass and the changes were minimal. > > > > That's great! This a box checked and means we should be close to a > release. > > Do you remember the other checklist items? > > There are 8 open tickets, otherwise: 1. URI 2. HTTP URI in client 3. Better docs 4. Better examples We're doing quite poorly for docs and examples. > The only thing I remember are: uri implementation and https (?). Am I > missing anything else? > > How close are you to HTTPS? If it can't be done soon then I suggest we get a release before returning to this later. G |
7 messages has been excluded from this view by a project administrator.
