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: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 15:51:45
|
Fernando Pelliccioni wrote: > Why not do > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > instead of > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) I prefer the second way- it's more expressive and it's standards-compliant. This is a bug in the Microsoft compiler. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 15:51:31
|
On Thu, Jun 3, 2010 at 11:16 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: > >> Well, it's not that simple you know. > > It never is :) and I know you have a lot more experience with this than me. I'm using cpp-netlib in our production app, and just trying to put out there my experiences. > That's good to know, cpp-netlib is in production somewhere! :D >> The reason is that the URL to get/post/delete/put/head is a runtime >> value. We do some pretty clever static+runtime dispatch to determine >> whether to create an https connection object that knows how to >> establish https connections and handle the request/response >> appropriately. > > That's maybe a fundamental difference in our use cases... the http/https part of the URL is *never* a runtime value for me, so there's no need for the static+runtime dispatch. Well, actually, it kinda is a runtime value for everyone using cpp-netlib. Even if it's hard-coded (the URL), it still has to be parsed at runtime. That means, at compile-time, there's no way for the library to know from a type standpoint that the URI is an HTTP or HTTPS URI. This is the reason there's a mix of static and runtime dispatch -- static dispatch for the tags, runtime dispatch for determining whether it's HTTP or HTTPS. > Might it be possible to factor out the dispatcher such that you have only as many dependencies as you wanted? > > For example > > typedef dispatcher<http> http_dispatcher; // only handles http URLS > typedef dispatcher<https> https_dispatcher; // only handles https URLS > typedef dispatcher<https, http> https_http_dispatcher; // handles https or http URLS > typedef dispatcher<https, http, ftp> https_http_ftp_dispatcher; // handles https or http or ftp URLS > > I know the names are unhandy, but at some level, dispatching is kind of an orthogonal task to what URL set is going to be used, and I don't see how it's going to be extensible to other URL types. > If you look at the way the dispatch happens, it's really simple: if it's an "https://..." then create an instance of an https_sync_connection object and get a handle to it using a reference to a sync_connection_base (the virtual base type). This is purely dynamic dispatch, no need for a layer for dispatching. :) It's the factory+strategy patterns combined, only the factory is static while the strategy is dynamic. :D >> The reason I opt for a macro to disable it is because I personally >> think you ought to know what you're doing with an HTTP client library >> if you specifically opt out of using SSL. The manifestation of this is >> as a macro you define that says explicitly that you don't want HTTPS >> support -- and the runtime dispatcher will just throw an exception if >> you give it an HTTPS URI. > > I'd maybe argue the opposite... the https use case is more complex, with more complex dependencies, so you ought to know what you're doing if you want to *include* https support. Plain http is about as vanilla as it gets. > That makes sense, but then I would solve it using macro's still -- adding a different header to include just HTTP is just wasteful IMO. I may be convinced otherwise, and as you know patches/pull-requests are totally welcome. :D >> Patience is a virtue > > Not intending to be impatient or complaining... whatever you decide is fine by me- you are the one doing the heavy lifting, and it totally your call. > That's alright, my version of the fix is already up in the 0.7-devel branch. :) -- Dean Michael Berris deanberris.com |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 15:43:18
|
I think it is good for readability. It's the first time that I see it ... :) On Thu, Jun 3, 2010 at 12:38 PM, Dean Michael Berris <mik...@gm... > wrote: > On Thu, Jun 3, 2010 at 11:34 PM, Fernando Pelliccioni > <fpe...@gm...> wrote: > > Perfect Duean, Great news!!! > > > > Only a question: > > > > Why not do > > > > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > > > > instead of > > > > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) > > > > ? > > > > Good question... I have no good answer except that the version with > the "not" reads better. > > It's a matter of taste -- I just might remove the 'not', 'and', and > 'or' keywords if I get tired of fighting it. ;) > > -- > Dean Michael Berris > deanberris.com > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 15:38:38
|
On Thu, Jun 3, 2010 at 11:34 PM, Fernando Pelliccioni <fpe...@gm...> wrote: > Perfect Duean, Great news!!! > > Only a question: > > Why not do > > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > > instead of > > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) > > ? > Good question... I have no good answer except that the version with the "not" reads better. It's a matter of taste -- I just might remove the 'not', 'and', and 'or' keywords if I get tired of fighting it. ;) -- Dean Michael Berris deanberris.com |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 15:35:10
|
Perfect Duean, Great news!!!
Only a question:
Why not do
if ( *!* boost::iequals(parts.scheme.substr(0, 5), "https") )
instead of
if ( *not *boost::iequals(parts.scheme.substr(0, 5), "https") )
?
Regards,
Fernando.
On Thu, Jun 3, 2010 at 11:27 AM, Dean Michael Berris <mik...@gm...
> wrote:
> On Thu, Jun 3, 2010 at 10:21 PM, Dean Michael Berris
> <mik...@gm...> wrote:
> > Hi Fernando!
> >
> > On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni
> > <fpe...@gm...> wrote:
> >>
> >> 1. Dependencies to OpenSSL.
> >> The
> "boost/network/protocol/http/impl/sync_connection_base.hpp"
> >> depends on "boost/network/protocol/http/impl/sync_connection_base.hpp"
> and
> >> the las depends on "boost/asio/ssl.hpp"
> >>
> >> I am not using secure connections.
> >>
> >
> > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall
> > be pushing soon a fix that allows users to define the
> > BOOST_NETWORK_NO_HTTPS command-line option to disable support for
>
> I meant, BOOST_NETWORK_NO_HTTPS macro not command-line option.
>
> > secure connections. I'm working on getting this tested as well locally
> > to make sure that the examples and other things can be built without
> > support for or dependency on OpenSSL.
> >
> >>
> >> 2. Compilation error.
> >> The "boost/network/uri/http/detail/parse_specific.hpp" file has
> the
> >> following lines:
> >>
> >> if (not boost::iequals(parts.scheme.substr(0, 4),
> "http"))
> >>
> >>
> >> and
> >>
> >> if (not boost::iequals(parts.scheme.substr(0, 5),
> "https"))
> >>
> >>
> >> The keyword "not" is undeclared.
> >>
> >> Could be this way?
> >>
> >> #define not !
> >>
> >
> > This is a notorious problem with MSVC 8/9 -- which is not a problem
> > with MSVC 10.
> >
> > I thought there was already a fix that should have fixed this, but I
> > don't know the correct search term. Someone has already sent in a
> > patch for this before, I can't believe it hasn't made it into the
> > library yet!
> >
> > Does anybody remember what that file is that should be included to
> > enable this in MSVC 8/9?
> >
>
> And Google is my friend: #include <ciso646>
>
> HTH
>
> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 15:19:05
|
Dean Michael Berris wrote: > Erik nelson wrote: >> I had this problem as well… I just commented out the stuff I didn’t need in >> sync_connection_base. In my opinion a better fix is to factor >> https_sync_connection out into a different header file that is only >> #included if the user includes, for example, a hypothetical >> protocol/https/client.hpp > Well, it's not that simple you know. It never is :) and I know you have a lot more experience with this than me. I'm using cpp-netlib in our production app, and just trying to put out there my experiences. > The reason is that the URL to get/post/delete/put/head is a runtime > value. We do some pretty clever static+runtime dispatch to determine > whether to create an https connection object that knows how to > establish https connections and handle the request/response > appropriately. That's maybe a fundamental difference in our use cases... the http/https part of the URL is *never* a runtime value for me, so there's no need for the static+runtime dispatch. Might it be possible to factor out the dispatcher such that you have only as many dependencies as you wanted? For example typedef dispatcher<http> http_dispatcher; // only handles http URLS typedef dispatcher<https> https_dispatcher; // only handles https URLS typedef dispatcher<https, http> https_http_dispatcher; // handles https or http URLS typedef dispatcher<https, http, ftp> https_http_ftp_dispatcher; // handles https or http or ftp URLS I know the names are unhandy, but at some level, dispatching is kind of an orthogonal task to what URL set is going to be used, and I don't see how it's going to be extensible to other URL types. > The reason I opt for a macro to disable it is because I personally > think you ought to know what you're doing with an HTTP client library > if you specifically opt out of using SSL. The manifestation of this is > as a macro you define that says explicitly that you don't want HTTPS > support -- and the runtime dispatcher will just throw an exception if > you give it an HTTPS URI. I'd maybe argue the opposite... the https use case is more complex, with more complex dependencies, so you ought to know what you're doing if you want to *include* https support. Plain http is about as vanilla as it gets. > Patience is a virtue Not intending to be impatient or complaining... whatever you decide is fine by me- you are the one doing the heavy lifting, and it totally your call. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:52:51
|
On Thu, Jun 3, 2010 at 10:49 PM, Dean Michael Berris <mik...@gm...> wrote: > > Patience is a virtue -- expect a push from me in a bit, although > expect things might be broken because I'm still working on the async > HTTP stuff, so for the brave please feel free to pull as soon as I > push and see if I really broke anything. ;) > And you can now test this from 0.7-devel on http://github.com/mikhailberis/cpp-netlib -- bug reports and violent reactions would be welcome in case it's broken by me. :) -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:49:52
|
On Thu, Jun 3, 2010 at 10:42 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > Fernando Pelliccioni wrote: > >> 1. Dependencies to OpenSSL. >> The "boost/network/protocol/http/impl/sync_connection_base.hpp" depends on >> "boost/network/protocol/http/impl/sync_connection_base.hpp" and the las >> depends on "boost/asio/ssl.hpp" > > I had this problem as well… I just commented out the stuff I didn’t need in > sync_connection_base. In my opinion a better fix is to factor > https_sync_connection out into a different header file that is only > #included if the user includes, for example, a hypothetical > protocol/https/client.hpp > Well, it's not that simple you know. The reason is that the URL to get/post/delete/put/head is a runtime value. We do some pretty clever static+runtime dispatch to determine whether to create an https connection object that knows how to establish https connections and handle the request/response appropriately. The reason I opt for a macro to disable it is because I personally think you ought to know what you're doing with an HTTP client library if you specifically opt out of using SSL. The manifestation of this is as a macro you define that says explicitly that you don't want HTTPS support -- and the runtime dispatcher will just throw an exception if you give it an HTTPS URI. > This was is very unsurprising… never use anything from protocol/https, and > you’ll never have a dependency on SSL. > I've already refactored the code locally so the HTTPS handling is already in a different file. The wiring though is surrounded by the macro as discussed above. Patience is a virtue -- expect a push from me in a bit, although expect things might be broken because I'm still working on the async HTTP stuff, so for the brave please feel free to pull as soon as I push and see if I really broke anything. ;) -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 14:42:27
|
Fernando Pelliccioni wrote: > 1. Dependencies to OpenSSL. > The "boost/network/protocol/http/impl/sync_connection_base.hpp" depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and the las depends on "boost/asio/ssl.hpp" I had this problem as well... I just commented out the stuff I didn't need in sync_connection_base. In my opinion a better fix is to factor https_sync_connection out into a different header file that is only #included if the user includes, for example, a hypothetical protocol/https/client.hpp This was is very unsurprising... never use anything from protocol/https, and you'll never have a dependency on SSL. Erik |
|
From: Kim G. <kim...@gm...> - 2010-06-03 14:38:39
|
Hi Dean, On Thu, Jun 3, 2010 at 16:21, Dean Michael Berris <mik...@gm...> wrote: > > This is a notorious problem with MSVC 8/9 -- which is not a problem > with MSVC 10. > > I thought there was already a fix that should have fixed this, but I > don't know the correct search term. Someone has already sent in a > patch for this before, I can't believe it hasn't made it into the > library yet! > > Does anybody remember what that file is that should be included to > enable this in MSVC 8/9? According to previous discussion it should be in iso646.h. See http://en.wikipedia.org/wiki/Iso646.h for more details. - Kim |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:27:47
|
On Thu, Jun 3, 2010 at 10:21 PM, Dean Michael Berris <mik...@gm...> wrote: > Hi Fernando! > > On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni > <fpe...@gm...> wrote: >> >> 1. Dependencies to OpenSSL. >> The "boost/network/protocol/http/impl/sync_connection_base.hpp" >> depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and >> the las depends on "boost/asio/ssl.hpp" >> >> I am not using secure connections. >> > > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall > be pushing soon a fix that allows users to define the > BOOST_NETWORK_NO_HTTPS command-line option to disable support for I meant, BOOST_NETWORK_NO_HTTPS macro not command-line option. > secure connections. I'm working on getting this tested as well locally > to make sure that the examples and other things can be built without > support for or dependency on OpenSSL. > >> >> 2. Compilation error. >> The "boost/network/uri/http/detail/parse_specific.hpp" file has the >> following lines: >> >> if (not boost::iequals(parts.scheme.substr(0, 4), "http")) >> >> >> and >> >> if (not boost::iequals(parts.scheme.substr(0, 5), "https")) >> >> >> The keyword "not" is undeclared. >> >> Could be this way? >> >> #define not ! >> > > This is a notorious problem with MSVC 8/9 -- which is not a problem > with MSVC 10. > > I thought there was already a fix that should have fixed this, but I > don't know the correct search term. Someone has already sent in a > patch for this before, I can't believe it hasn't made it into the > library yet! > > Does anybody remember what that file is that should be included to > enable this in MSVC 8/9? > And Google is my friend: #include <ciso646> HTH -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:21:44
|
Hi Fernando! On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni <fpe...@gm...> wrote: > Hello, > > I am new in the list. Welcome! :) > I write this because I want to talk to Dean or Glyn about the NetLib. You wrote to the right place. :D > > I downloaded cpp-netlib-0.5, cpp-netlib-0.6 and cpp-netlib-0.61yesterday. > I found some problems in the library. > Cool! :) > I tested the "Hello World Client" example on MSVC 9.0 on Windows XP. > The issues are: > > 1. Dependencies to OpenSSL. > The "boost/network/protocol/http/impl/sync_connection_base.hpp" > depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and > the las depends on "boost/asio/ssl.hpp" > > I am not using secure connections. > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall be pushing soon a fix that allows users to define the BOOST_NETWORK_NO_HTTPS command-line option to disable support for secure connections. I'm working on getting this tested as well locally to make sure that the examples and other things can be built without support for or dependency on OpenSSL. > > 2. Compilation error. > The "boost/network/uri/http/detail/parse_specific.hpp" file has the > following lines: > > if (not boost::iequals(parts.scheme.substr(0, 4), "http")) > > > and > > if (not boost::iequals(parts.scheme.substr(0, 5), "https")) > > > The keyword "not" is undeclared. > > Could be this way? > > #define not ! > This is a notorious problem with MSVC 8/9 -- which is not a problem with MSVC 10. I thought there was already a fix that should have fixed this, but I don't know the correct search term. Someone has already sent in a patch for this before, I can't believe it hasn't made it into the library yet! Does anybody remember what that file is that should be included to enable this in MSVC 8/9? > > 3. Async operations. > This is not an error, but I think the library should support > asynchronous operations, like ASIO. I have not found it. > I hear you, I'm working on it as I take a break and respond to you on the list. :) > > Sorry if this mail was sent to a wrong list. In this case, please tell me > where I can send. You sent it to the right list. :) > Count on me to lend a hand with the development of netlib > That sounds great! Thanks Fernando! :) -- Dean Michael Berris deanberris.com |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 13:56:51
|
Hello,
I am new in the list.
I write this because I want to talk to Dean or Glyn about the NetLib.
I downloaded cpp-netlib-0.5, cpp-netlib-0.6 and cpp-netlib-0.61yesterday.
I found some problems in the library.
I tested the "Hello World Client" example on MSVC 9.0 on Windows XP.
The issues are:
1. Dependencies to OpenSSL.
The "boost/network/protocol/http/impl/sync_connection_base.hpp"
depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and
the las depends on "boost/asio/ssl.hpp"
I am not using secure connections.
2. Compilation error.
The "boost/network/uri/http/detail/parse_specific.hpp" file has the
following lines:
*if (not boost::iequals(parts.scheme.substr(0, 4), "http"))*
and
*if (not boost::iequals(parts.scheme.substr(0, 5), "https"))*
The keyword "not" is undeclared.
Could be this way?
*#define not !*
3. Async operations.
This is not an error, but I think the library should support
asynchronous operations, like ASIO. I have not found it.
Sorry if this mail was sent to a wrong list. In this case, please tell me
where I can send.
Count on me to lend a hand with the development of netlib
Regards,
Fernando Pelliccioni.
*
<http://sourceforge.net/projects/cpp-netlib/files/cpp-netlib/0.5/cpp-netlib-0.5.zip/download>
*
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-01 15:36:24
|
Dean Michael Berris wrote:
> On Fri, May 28, 2010 at 12:42 AM, Nelson, Erik - 2 wrote:
>> if I call http::client.post() with a payload (body), it looks to me like
>> that body gets fully copied at least 5 times in cpp-netlib before it
>> goes down the wire if I understand correctly.
> Hmmm... That's odd. Are you just looking at the code or are you
> tracing that the message is being copied 5 times?
Tracing it (Visual Studio 2008, debug mode, apologies for any mistakes-not everything is clear to me)... if I call
http::client::post (request request_, string_type const & content_type, string_type const & body_) {
body(body_) calls impl::body_directive body(std::string body_) which makes a copy (1) in its signature
impl::body() creates a struct impl::body_directive which makes two copies, one in the constructor signature (2) and another as its private member (3)
request_ << body(body_) calls impl::body_directive operator(), which makes a copy by way of string::operator= (4)
http::client::post calls http::client::post(request_), which calls http::client::sync_request_skeleton
http::client::sync_request_skeleton calls simple_connection_policy::connection_impl::send_request, which makes a deep copy of the entire request in the function signature (5)
simple_connection_policy::connection_impl::send_request calls http_sync_connection::send_request_impl
http_sync_connection::send_request_impl calls detail::connection_helper::create_request, which makes a deep copy of the entire request in the function signature (6)
detail::connection_helper::create_request makes another copy (7) in the line 'string_type body_ = body(request_);' and another copy is streamed into request_stream (8)
so that's 8 copies inside cpp-netlib by my count, nine if you include the original body string that I passed in. Some of them might be optimized away by the compiler under some settings, but that's how it looks to me.
> Are you trying with the latest in master or with a
> previous release of the library?
Latest in master, checked out last week.
Erik
|
|
From: Dean M. B. <mik...@gm...> - 2010-05-29 03:22:03
|
On Fri, May 28, 2010 at 8:03 PM, Jeroen Habraken <vex...@gm...> wrote: > > It might be an idea to support boost::property_tree, the XML backend > is based on rapidxml but unfortunately lacking in documentation. > Maybe we can do something about the documentation too. If we do use it (which would be a good idea definitely) then it would be nice to see if it's easy enough to document. I think a lot of the Boost libraries would appreciate documentation patches. Thanks for pointing it out Jeroen! -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-05-29 03:20:14
|
On Fri, May 28, 2010 at 5:10 PM, Glyn Matthews <gly...@gm...> wrote: > > > On 28 May 2010 05:49, Dean Michael Berris <mik...@gm...> wrote: >> >> >> The SMTP client will need a lot of thinking on my part -- which I plan >> to work on with Marshall because he already has a lot of experience in >> that field. It's also one of those things I kinda hinted would have to >> be implemented within the year which works well with the MIME library >> that Marshall is working on. ;) > > +2 for this. > Definitely something worth starting to implement. A functional client should be alright, and I think I can get a lot of input/help from Marshall on getting it done. I just don't feel like leaving the HTTP client/server implementation in the state it is currently in. People have been asking for the asynchronous and streaming HTTP client/server which makes a lot of sense and seems to be a cool enough challenge for me to tackle first. ;) Besides, a lot of my experience is really in this protocol so I'm more inclined to work on it. Although I would really support Marshall in his fixing the MIME library along with other things -- and maybe moving into the SMTP client implementation. >> >> That's cool! Definitely we can discuss that here. >> >> I think we better start a thread around it. > > I will do, in a few weeks. The source is already at > http://github.com/glynos/cpp-netlib in branch xmpp for anyone who wants to > take a look. Cool, I'll look forward to that. :) >> >> I think one good thing to do is to link to the PDF of the paper from >> the documentation. That should be alright. I plan on writing more >> papers about different things in the coming weeks and should be >> something worth looking out for. ;) >> >> And, please feel free to take anything from the document and use it in >> the generated documentation. I'll let you decide which ones are worth >> pulling into the docs. :) > > OK! Did you notice I was avoiding that documentation work? :D You're doing a great job, please take whatever seems appropriate for the online documentation. :) >> >> So... really we just want to get 1.0 out the door and submit for a >> review. I still maintain that 1.0 should have: >> >> * asynchronous HTTP client >> * (e)smtp client >> * MIME >> * xmpp > > I think that's possible inside the scope. > Just a question about the MIME implementation: there was a talk at BoostCon > about this, is possible to find out any more about this? A video or a > transcript? I'd be interested to learn more about this. > Marshall gave the talk, and I think he's still busy dealing with the mountain of video that he so graciously took of all the talks. I think there are a few things that stuck out, which are generally technical issues that seem to have some possible solutions that just need to get done -- like a lot of the work, it just takes time. :) >> >> We're running out of numbers in between 0.6 and 1.0 (assuming that we >> stop at 0.9 and "upgrade" to 1.0) so it would be good if we can get a >> move on with these things. Help would really be appreciated. > > after 0.9 we can go to 0.10, 0.11, etc. It doesn't have to be decimal. > I was thinking of that, but I don't really want to go there. :D -- Dean Michael Berris deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-05-28 12:03:44
|
On 28 May 2010 12:28, Mark Wright <mar...@in...> wrote: >> > Mark wrote: >> > I think it would be really great if cpp-netlib had more support for >> > XML REST web server and clients, and smtp client, so I vote for: >> > >> > * web framework >> > * more message algorithms (transforms, renderers) >> > * smtp client >> > >> > cpp-netlib REST XML clients and servers that are interopable with >> > C# WCF REST clients and servers would be really neat. Then it >> > would be interesting to run some benchmark tests to see how >> > C++ netlib XML REST clients and servers perform vs C# clients >> > and servers. Some obvious ideas for the XML parsing is to use >> > Rapid XML: >> > >> > http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance > >> Glyn wrote: >> XML parsing is something that's going to crop up over again. For the XMPP >> client, I intend to write some simple backends around third party libs such >> as expat and libxml2 (not rapidxml as it's not an incremental parser). >> Rapid XML could still be useful for other parts. In any case, in the >> absence of Boost.Xml we'd have to make a lot of decisions about this >> ourselves so we don't end up writing our own XML library. > >> Thank you too for your input. You've obviously given some thought to this, >> is it possible that you could contribute? > > Hi Glyn, Dean and everyone, > > Yes :-) Obviously I am particulary interested in REST XML stuff. > For that I was wondering if (just some obvious ideas you have probably > already thought of): > > - the half async part could read in the entire XML message, hopefully > just using the HTTP message length to know when it has all of the message > (I'm not really sure if that will work or not) > - then pass it to a thread in a thread pool (the sync half), that then > parses the XML with an XML parser. > - Dean suggested earlier: "URI pattern-based dispatch (ala Rails, or > Django/Tornado)" that could call the appropriate handler method (in > the same thread that has already parsed the XML). > > Rapid XML seems appealing for little benchmarks vs C# WCF. > >> Dean wrote: >> REST-full web services can definitely be already implemented with the >> HTTP server template. Are you looking for an example on how to do >> this? > > An an example or framework or guidance on how go about writing some > stuff for this would be neat. > >> A framework wouldn't be very hard to implement, but will depend >> largely on conventions that most web services already need -- URI >> handling/routing, request parsing, REST method dispatch, etc. I'll >> look into writing up a simple example and then allowing others to >> extend into a full framework. I can be involved in that process too >> and it would be interesting to see where that goes. > > That's neat, thanks, I can help. > >> As far as XML is concerned, it might be outside the scope of the library. >> [snip links] > >> Thanks very much for the links, I've read pretty much all of these before. :) > > I guess I kind of expected you would have :-) > >> > >> > Thanks very much, >> > > >> Thank you very much too, I'll look into implementing the web framework >> parts in an example first and let others pick up if they find it >> interesting to work on too. I'll schedule that in the 0.8 release and >> focus on the HTTP parts for 0.7. > >> Have a great day and I hope this helps! > > Great, thanks, have a great day. > > Thanks, Mark > It might be an idea to support boost::property_tree, the XML backend is based on rapidxml but unfortunately lacking in documentation. Jeroen |
|
From: Mark W. <mar...@in...> - 2010-05-28 10:28:48
|
> > Mark wrote: > > I think it would be really great if cpp-netlib had more support for > > XML REST web server and clients, and smtp client, so I vote for: > > > > * web framework > > * more message algorithms (transforms, renderers) > > * smtp client > > > > cpp-netlib REST XML clients and servers that are interopable with > > C# WCF REST clients and servers would be really neat. Then it > > would be interesting to run some benchmark tests to see how > > C++ netlib XML REST clients and servers perform vs C# clients > > and servers. Some obvious ideas for the XML parsing is to use > > Rapid XML: > > > > http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance > Glyn wrote: > XML parsing is something that's going to crop up over again. For the XMPP > client, I intend to write some simple backends around third party libs such > as expat and libxml2 (not rapidxml as it's not an incremental parser). > Rapid XML could still be useful for other parts. In any case, in the > absence of Boost.Xml we'd have to make a lot of decisions about this > ourselves so we don't end up writing our own XML library. > Thank you too for your input. You've obviously given some thought to this, > is it possible that you could contribute? Hi Glyn, Dean and everyone, Yes :-) Obviously I am particulary interested in REST XML stuff. For that I was wondering if (just some obvious ideas you have probably already thought of): - the half async part could read in the entire XML message, hopefully just using the HTTP message length to know when it has all of the message (I'm not really sure if that will work or not) - then pass it to a thread in a thread pool (the sync half), that then parses the XML with an XML parser. - Dean suggested earlier: "URI pattern-based dispatch (ala Rails, or Django/Tornado)" that could call the appropriate handler method (in the same thread that has already parsed the XML). Rapid XML seems appealing for little benchmarks vs C# WCF. > Dean wrote: > REST-full web services can definitely be already implemented with the > HTTP server template. Are you looking for an example on how to do > this? An an example or framework or guidance on how go about writing some stuff for this would be neat. > A framework wouldn't be very hard to implement, but will depend > largely on conventions that most web services already need -- URI > handling/routing, request parsing, REST method dispatch, etc. I'll > look into writing up a simple example and then allowing others to > extend into a full framework. I can be involved in that process too > and it would be interesting to see where that goes. That's neat, thanks, I can help. > As far as XML is concerned, it might be outside the scope of the library. > [snip links] > Thanks very much for the links, I've read pretty much all of these before. :) I guess I kind of expected you would have :-) > > > > Thanks very much, > > > Thank you very much too, I'll look into implementing the web framework > parts in an example first and let others pick up if they find it > interesting to work on too. I'll schedule that in the 0.8 release and > focus on the HTTP parts for 0.7. > Have a great day and I hope this helps! Great, thanks, have a great day. Thanks, Mark |
|
From: Glyn M. <gly...@gm...> - 2010-05-28 09:15:47
|
Hi Matt, On 28 May 2010 09:38, Mark Wright <mar...@in...> wrote: > Hi, > > cpp-netlib is really neat, thanks for writing this great library. > Thanks! > > I think it would be really great if cpp-netlib had more support for > XML REST web server and clients, and smtp client, so I vote for: > > * web framework > * more message algorithms (transforms, renderers) > * smtp client > > cpp-netlib REST XML clients and servers that are interopable with > C# WCF REST clients and servers would be really neat. Then it > would be interesting to run some benchmark tests to see how > C++ netlib XML REST clients and servers perform vs C# clients > and servers. Some obvious ideas for the XML parsing is to use > Rapid XML: > > http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance > > XML parsing is something that's going to crop up over again. For the XMPP client, I intend to write some simple backends around third party libs such as expat and libxml2 (not rapidxml as it's not an incremental parser). Rapid XML could still be useful for other parts. In any case, in the absence of Boost.Xml we'd have to make a lot of decisions about this ourselves so we don't end up writing our own XML library. > and the Half-Sync/Half-Async pattern: > > http://www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf > > For C# REST XML, there is an article and examples at: > > http://msdn.microsoft.com/en-us/library/aa395208.aspx > > I guess you would have seen the ASIO blog articles about co-routines, > which may make it easier to implement some protocols, like smtp: > > > http://blog.think-async.com/2010/03/potted-guide-to-stackless-coroutines.html > > http://blog.think-async.com/2009/08/composed-operations-coroutines-and-code.html > http://blog.think-async.com/2009/08/secret-sauce-revealed.html > http://blog.think-async.com/2009/07/wife-says-i-cant-believe-it-works.html > > Thanks very much, > > Thank you too for your input. You've obviously given some thought to this, is it possible that you could contribute? <https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel> |
|
From: Glyn M. <gly...@gm...> - 2010-05-28 09:11:05
|
On 28 May 2010 05:49, Dean Michael Berris <mik...@gm...> wrote: > On Thu, May 27, 2010 at 10:29 PM, Glyn Matthews <gly...@gm...> > wrote: > > > > On 27 May 2010 15:48, Dean Michael Berris <mik...@gm...> > wrote: > >> > [snip] > >> > >> * asynchronous http client > >> * streaming http client support > >> * web framework > >> * smtp client > >> * more message algorithms (transforms, renderers) > >> * more message specializations (for CString, QString, etc.) > >> * xmpp client > >> > > > > Are all these equally hard or time-consuming? > > From the outset, I'd say yes -- they all require pretty much the same > amount of work and the same amount of time to complete, so I'm > thinking of which one would have most of my effort. > > > Some tests for message > > specializations would be worthwhile; an SMTP client could be good to > prove > > the architecture. > > I think we already have the basics of the message specializations > tests in there (the one that uses the template based testing of > Boost.Test) -- it's just a matter of adding more, and I think anyone > can pick that up and run away with it. :) > > The SMTP client will need a lot of thinking on my part -- which I plan > to work on with Marshall because he already has a lot of experience in > that field. It's also one of those things I kinda hinted would have to > be implemented within the year which works well with the MIME library > that Marshall is working on. ;) > +2 for this. > > > I have started a branch in my own fork for the XMPP client, so I hope you > > provide discussion on that (I'll push some more changes when I get home > this > > evening). > > That's cool! Definitely we can discuss that here. > > I think we better start a thread around it. > I will do, in a few weeks. The source is already at http://github.com/glynos/cpp-netlib in branch xmpp for anyone who wants to take a look. >> > >> Of course, documentation is another thing that we all agree could be > >> improved -- and I've pretty much indicated my preference for RST by > >> writing up my BoostCon paper in that format. Are there any specific > >> requests for improvement in the documentation that you would like me > >> personally to address? > > > > Is there anything of your paper and presentation you could incorporate > into > > the docs at http://cpp-netlib.github.com/ ? > > I think one good thing to do is to link to the PDF of the paper from > the documentation. That should be alright. I plan on writing more > papers about different things in the coming weeks and should be > something worth looking out for. ;) > > And, please feel free to take anything from the document and use it in > the generated documentation. I'll let you decide which ones are worth > pulling into the docs. :) > OK! > > > Do we have a clearer definition of "Boost-worthy"? When you were at > > BoostCon, did you get any guage of what might be a minimum acceptable > > implementation? > > > > Well, *I* have a good idea on what Boost-worthy means: > > * Follows Boost guidelines on documentation, licensing, namespace > requirements, etc. > * Is implemented well, sufficiently cross-platform, and delivers the > features as advertised > * Something we all can be proud of to show to other people > > Someone actually asked me what the plan was, and I said I wanted to > get it to a point where it is 1.0-worthy and within the year submit > for review. My personal target is September, which is just a few > months away. It should be easier now for me because I have a spiffy > new machine to build/test on and thanks to Microsoft Philippines, > access to an evaluation version of Visual Studio 2010 Professional -- > which apparently is a larger audience in Boost. > > So... really we just want to get 1.0 out the door and submit for a > review. I still maintain that 1.0 should have: > > * asynchronous HTTP client > * (e)smtp client > * MIME > * xmpp > I think that's possible inside the scope. Just a question about the MIME implementation: there was a talk at BoostCon about this, is possible to find out any more about this? A video or a transcript? I'd be interested to learn more about this. > > We're running out of numbers in between 0.6 and 1.0 (assuming that we > stop at 0.9 and "upgrade" to 1.0) so it would be good if we can get a > move on with these things. Help would really be appreciated. > after 0.9 we can go to 0.10, 0.11, etc. It doesn't have to be decimal. |
|
From: Glyn M. <gly...@gm...> - 2010-05-28 09:09:54
|
Hi Matt, On 28 May 2010 04:48, Matt Trentini <mat...@gm...> wrote: > Heya Dean, > > As always, thanks to you, Glyn and everyone else associated with the > cpp-netlib; we're using it on a live project and have found it very > useful! > Thanks very much Matt! I'm happy to hear that cpp-netlib is being used in the wild. > > > * asynchronous http client > > Async HTTP is the only feature in the list that we require. We've > actually managed to cobble together an async solution based on > cpp-netlib but it's so ugly that I haven't contributed it back. We > did have plans to tidy it up and submit it to you guys but finding > time is proving *very* difficult. > > I would suggest you contribute it regardless of how ugly you think it is at this stage: you would be likely to get some good feedback from other community members, it seems this is a popular request. Github makes this process easy ;) |
|
From: Dean M. B. <mik...@gm...> - 2010-05-28 09:02:05
|
On Fri, May 28, 2010 at 4:29 PM, Jeroen Habraken <vex...@gm...> wrote: > > On 27 May 2010 15:48, Dean Michael Berris <mik...@gm...> wrote: [snip] > > I feel like I have little more to add to this conversation. As most > others I think the HTTP stuff (and the core parser) should get top > priority, for reasons already covered. > Cool, so I can count on your continued support/implementation of the URI parser? :D It looks like we're going to need some modifications to support non-HTTP URI's like email addresses and Jabber/XMPP ID's. :) Have a good one Jeroen and I look forward to more of your contributions! :D -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-05-28 09:00:30
|
On Fri, May 28, 2010 at 3:38 PM, Mark Wright <mar...@in...> wrote: > Hi, > > cpp-netlib is really neat, thanks for writing this great library. > Thanks Mark! > I think it would be really great if cpp-netlib had more support for > XML REST web server and clients, and smtp client, so I vote for: > > * web framework > * more message algorithms (transforms, renderers) > * smtp client > > cpp-netlib REST XML clients and servers that are interopable with > C# WCF REST clients and servers would be really neat. Then it > would be interesting to run some benchmark tests to see how > C++ netlib XML REST clients and servers perform vs C# clients > and servers. REST-full web services can definitely be already implemented with the HTTP server template. Are you looking for an example on how to do this? A framework wouldn't be very hard to implement, but will depend largely on conventions that most web services already need -- URI handling/routing, request parsing, REST method dispatch, etc. I'll look into writing up a simple example and then allowing others to extend into a full framework. I can be involved in that process too and it would be interesting to see where that goes. As far as XML is concerned, it might be outside the scope of the library. [snip links] Thanks very much for the links, I've read pretty much all of these before. :) > > Thanks very much, > Thank you very much too, I'll look into implementing the web framework parts in an example first and let others pick up if they find it interesting to work on too. I'll schedule that in the 0.8 release and focus on the HTTP parts for 0.7. Have a great day and I hope this helps! -- Dean Michael Berris deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-05-28 08:30:03
|
Hi,
On 27 May 2010 15:48, Dean Michael Berris <mik...@gm...> wrote:
> Hi Guys,
>
> Now that Boost.Trunk has an updated BOOST_SPIRIT_VERSION macro that we
> can switch on for the transform_action thingy, I guess that will be
> solved in my next push. Having said that, I would like to know what
> next you would like to see in the next release of cpp-netlib. I have
> some time on my hands now and a spanking new machine to play with
> while I'm pretty much idling and doing high level stuff. Please
> indicate your votes so I can focus my energies (and other people
> interested in contributing) towards completing something that matters
> to those already in the list:
>
> * asynchronous http client
> * streaming http client support
> * web framework
> * smtp client
> * more message algorithms (transforms, renderers)
> * more message specializations (for CString, QString, etc.)
> * xmpp client
>
> My personal leaning is towards more of the HTTP stuff, but I guess I
> can say that the current state of the HTTP client seems sufficient for
> most of the use cases I (or most users, I imagine) would ever need 90%
> of the time. I just want to know if people in the list find more
> important things for me to work on.
>
> Of course, documentation is another thing that we all agree could be
> improved -- and I've pretty much indicated my preference for RST by
> writing up my BoostCon paper in that format. Are there any specific
> requests for improvement in the documentation that you would like me
> personally to address?
>
> The reason I ask is because I want to bring cpp-netlib to a level
> where it would be a viable alternative to other HTTP libraries already
> in the market. I'm thinking of pitching it as a library that can solve
> most, if not all of your HTTP client and HTTP server needs. I also
> would like to bring it to a level that would be Boost-worthy by the
> end of the year, so that either I or others contributing to the effort
> can talk about it in BoostCon 2011. ;)
>
> So if you have any specific requests that are not on the list that you
> feel is really important, then I suggest you let me know now before I
> put my head down again and start going down the rabbit hole of massive
> refactoring and gutting of the HTTP implementation once again. :)
>
> Oh, and as a parting shot, the following will now compile as a
> one-liner-http-get of the boost website:
>
> cout << body(http::client().get(http::client::request("http://www.boost.org/"))
> << endl;
>
> Have a great day and I hope to hear from you soon! :)
>
> --
> Dean Michael Berris
> deanberris.com
>
I feel like I have little more to add to this conversation. As most
others I think the HTTP stuff (and the core parser) should get top
priority, for reasons already covered.
Regards,
Jeroen
|
|
From: Mark W. <mar...@in...> - 2010-05-28 07:38:46
|
Hi, cpp-netlib is really neat, thanks for writing this great library. I think it would be really great if cpp-netlib had more support for XML REST web server and clients, and smtp client, so I vote for: * web framework * more message algorithms (transforms, renderers) * smtp client cpp-netlib REST XML clients and servers that are interopable with C# WCF REST clients and servers would be really neat. Then it would be interesting to run some benchmark tests to see how C++ netlib XML REST clients and servers perform vs C# clients and servers. Some obvious ideas for the XML parsing is to use Rapid XML: http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance and the Half-Sync/Half-Async pattern: http://www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf For C# REST XML, there is an article and examples at: http://msdn.microsoft.com/en-us/library/aa395208.aspx I guess you would have seen the ASIO blog articles about co-routines, which may make it easier to implement some protocols, like smtp: http://blog.think-async.com/2010/03/potted-guide-to-stackless-coroutines.html http://blog.think-async.com/2009/08/composed-operations-coroutines-and-code.html http://blog.think-async.com/2009/08/secret-sauce-revealed.html http://blog.think-async.com/2009/07/wife-says-i-cant-believe-it-works.html Thanks very much, Mark |
7 messages has been excluded from this view by a project administrator.
