Menu
▾
▴
cpp-netlib-devel
|
From: Dean M. B. <mik...@gm...> - 2010-05-27 13:48:57
|
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
|
|
From: Glyn M. <gly...@gm...> - 2010-05-27 14:29:57
|
Hola Dean, 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 > > Are all these equally hard or time-consuming? Some tests for message specializations would be worthwhile; an SMTP client could be good to prove the architecture. 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). Additionally, you can implement more examples. I can think of more interesting to do with the HTTP server, if you have webspace available we could host some cpp-netlib project-related things (eating our own dog food could be useful to find any further issues and to showcase our work). > 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? > Is there anything of your paper and presentation you could incorporate into the docs at http://cpp-netlib.github.com/ ? I have a short to-do list for this, including: * Clear directions on how to get cpp-netlib (both packages and git source) * Clear information on how to run the examples * More on the theory behind the design * Extension points for new protocols * More on URI docs, it's a little neglected > 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. ;) > > 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? > 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! :) > I will be away all next week, but over the rest of the summer I'd like to put more time into this project. Thanks, G |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-05-27 16:42:59
|
Dean Michael Berris wrote: > 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 Since you asked :) I wouldn't mind a little more focus on efficiency... 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. In my application, I routinely send 10-20MB messages. I haven't done any testing but it seems to me that there might be a way to do this a little more efficiently. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-05-28 03:52:55
|
On Fri, May 28, 2010 at 12:42 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: > >> 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 > > Since you asked :) I wouldn't mind a little more focus on efficiency... > 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? The copy should only happen once and only if there's a redirect encountered. Are you trying with the latest in master or with a previous release of the library? > In my application, I routinely send 10-20MB messages. I haven't done > any testing but it seems to me that there might be a way to do this a > little more efficiently. > Please let me know where these copies occur and when. I can try it out on my own but it looks like you've looked into it already -- pointers greatly appreciated. Thanks for your input Erik! -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-05-27 18:55:04
|
Dean Michael Berris wrote: > 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: The streaming http client support seems pretty useful to me, both on the client and server sides. Erik |
|
From: Matt T. <mat...@gm...> - 2010-05-28 02:48:18
|
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!
> * 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.
Actually, I should be more specific here. The critical requirement
for us is to allow *timeouts* on http requests. But I think that -
internally - you'll need to move the implementation to async asio
calls to allow the timeout to work correctly. At least that's what we
did - we initialised a deadline_timer and checked if it had expired
after each stage of the http request.
> Are there any specific requests for improvement in the documentation that you would like me
> personally to address?
An example with a threadpool would be nice: Push an http request into
a threadpool and get a callback when it's been completed (or timed
out).
> cout << body(http::client().get(http::client::request("http://www.boost.org/")) << endl;
Excellent!
Thanks again,
Matt
PS, when I tried to download the source in either zip or tgz through
github a virus was found (by github):
Virus/PUS: "Email-Worm.Win32.Plexus.a" found!
It was in one of the test messages:
http://github.com/mikhailberis/cpp-netlib/blob/master/libs/mime/test/TestMessages/00001136
Is this intended??
|
|
From: Dean M. B. <mik...@gm...> - 2010-05-28 04:15:24
|
Hey Matt!
On Fri, May 28, 2010 at 10:48 AM, 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!
>
You're welcome, this means a great deal to know that you're using it
in a live project already! You've just made my day. :)
>> * 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 know how that feels.
I actually have done some work before on a cpp-netlib fork before that
unfortunately they haven't authorized to be released back into
cpp-netlib -- and one of the things I did there was actually support a
real asynchronous HTTP client. Now though we have an opportunity of
implementing something different, using Boost.Thread's futures for a
real asynchronous HTTP client. Of course though that would introduce a
few things like making an HTTP client that's actually an active
object, and that will require a bit of gutting the current
implementation.
Fear not though, it sounds like a lot of work but with the magic of
template specialization we'd be leaving a lot of the stuff untouched
-- although later on it would be good to merge things... Scary, but
definitely doable.
> Actually, I should be more specific here. The critical requirement
> for us is to allow *timeouts* on http requests. But I think that -
> internally - you'll need to move the implementation to async asio
> calls to allow the timeout to work correctly. At least that's what we
> did - we initialised a deadline_timer and checked if it had expired
> after each stage of the http request.
>
Yes, we'd have to gut the current sync implementation to use futures
too for this to become real. The complications of adding timeouts
would be something to consider deeply first though, what do you do
when a timeout occurs, do you retry? do you throw? do you return a
message that says that something went wrong in the body?
Lots of questions that need to be answered first before we go about
sprinkling in timeout support for requests. ;)
If you or anybody would like to take this on too or have a proposal on
how to fix it, then I'm all ears and very supportive. I love github
and encourage everyone to fork and do crazy things with cpp-netlib. :)
>> Are there any specific requests for improvement in the documentation that you would like me
>> personally to address?
>
> An example with a threadpool would be nice: Push an http request into
> a threadpool and get a callback when it's been completed (or timed
> out).
>
I think this would require a little bit of help. I intend on hiding
the threadpool into a single thread and turning the asynchronous
client into an active object.
>> cout << body(http::client().get(http::client::request("http://www.boost.org/")) << endl;
>
> Excellent!
>
Thanks!
> Thanks again,
> Matt
>
You're very much welcome, thanks for the feedback Matt!
> PS, when I tried to download the source in either zip or tgz through
> github a virus was found (by github):
>
> Virus/PUS: "Email-Worm.Win32.Plexus.a" found!
>
> It was in one of the test messages:
>
> http://github.com/mikhailberis/cpp-netlib/blob/master/libs/mime/test/TestMessages/00001136
>
> Is this intended??
>
I would say that's not intentional, and that's part of the MIME
library tests. I've copied Marshall to this email so that he can take
a look and maybe do something about the offending email.
Thanks for letting us know!
--
Dean Michael Berris
deanberris.com
|
|
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 03:50:24
|
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. ;) > 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 plan on stabilizing the master at this time and push a 0.6.1 for the MSVC 10 users. > Additionally, you can implement more examples. I can think of more > interesting to do with the HTTP server, if you have webspace available we > could host some cpp-netlib project-related things (eating our own dog food > could be useful to find any further issues and to showcase our work). > Examples, yes. :) Unfortunately I don't have a server where I have root privileges to run on port 80. If anybody is willing to volunteer some public IP and a server that can run a cpp-netlib developed service that would be *super*. >> >> 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. :) > I have a short to-do list for > this, including: > * Clear directions on how to get cpp-netlib (both packages and git source) > * Clear information on how to run the examples > * More on the theory behind the design > * Extension points for new protocols > * More on URI docs, it's a little neglected All sound good to me, let's git-r-done! :D >> >> 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. ;) >> > > 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 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. > > I will be away all next week, but over the rest of the summer I'd like to > put more time into this project. Cool, definitely much appreciated Glyn! > Thanks, Thank you too! :) -- Dean Michael Berris deanberris.com |
|
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 |
|
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: 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: 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: 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: 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: 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: 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: 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: 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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X