Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
David
@dasloop
Seems that QNetworkCookie::parseCookies wants cookies separated by new lines, while the one that arrive to SessionStore::session are separated by ; ...
This makes SessionStore::session just consider one, the first cookie.
I´m not sure if this is a problem with Tufao or it comes from another place...
Vinícius dos Santos Oliveira
@vinipsmaker
I don't remember the code well enough to reply this just from my mind
I'll have to check the code later
Could you file an issue on GitHub please? If it's not a Tufão problem, I may just close the issue and direct you to a better place
David
@dasloop
OK I will create the issue.
BTW, as Tufao is no longer under development, any suggestion for a similar library? Your new one (future boost) is ready?
Vinícius dos Santos Oliveira
@vinipsmaker
I don't recommend my new library yet (unless you're okay with API breaking a few moments until it enters in Boost)
My new library may be more robust in quality, but I can only really guarantee API stability once it enters Boost
David
@dasloop
asiohttpserver ?
Vinícius dos Santos Oliveira
@vinipsmaker
@dasloop: yes
Bedeho Mender
@bedeho
hi, how would you compare Tufao with https://github.com/Microsoft/cpprestsdk ?
Vinícius dos Santos Oliveira
@vinipsmaker
hi
Features - HTTP client/server, JSON, URI, asynchronous streams, WebSockets client, oAuth
Tufão doesn't handle JSON, but I believe there is something to handle it in Qt itself
Tufão doesn't handle oAuth either. You'd have to implement that
Let me check further
PPL Tasks
Tufão is built on top of Qt and follows Qt's asynchronous foundation (QCoreApplication and signals)
Nowadays I believe this is a bad choice and the perfect choice is Asio + coroutines support (which means I don't believe in PPL tasks either)
That's why I started a new project a couple of years ago funded by Google Summer of Code, Boost.Http. Boost.Http doesn't do all Tufão does. However, what Boost.Http does, it does better than Tufão
There is a text of mine that goes into more detail about asynchronous paradigms if you are interested: https://vinipsmaker.wordpress.com/2015/11/26/multitasking-styles-event-loops-and-asynchronous-programming/
I'm currently writing a new text that expands the section of "active style vs passive style". It should be ready in a couple of months
Vinícius dos Santos Oliveira
@vinipsmaker
I participate on the discussion of async I/O on Rust too: rust-lang/rfcs#1081
Currently I only do maintenance releases of Tufão (there was a few ones just some days ago)
@bedeho: I think that's about it. You can ask me more if you're interested.
Bedeho Mender
@bedeho
@vinipsmaker thanks for that response, seems like you are suggesting I may want to consider cpprestdk then
Vinícius dos Santos Oliveira
@vinipsmaker
Yes. It sounds like that. It's you who need to analyse it though. Never let people make choices for you.
Bedeho Mender
@bedeho
thank you for that frank advice, really appreciate it!
Vinícius dos Santos Oliveira
@vinipsmaker
Nowadays I wouldn't use Tufão (or anything else). I'm trying to have something that can be standardized in included in the ISO C++ standard.
Bedeho Mender
@bedeho
that would be fantastic!
Vinícius dos Santos Oliveira
@vinipsmaker
cpprestsdk may be more maintained than Tufão for now. So it seems like a better short-term/mid-term solution
Bedeho Mender
@bedeho
I dont like having to use these third party libs all the time, such a pain to manage the dependencies
Vinícius dos Santos Oliveira
@vinipsmaker
Keep an eye on this project if you're interested: https://boostgsoc14.github.io/boost.http/
I'm collaborating with the author of Beast.Http too, so there is one more place to follow: https://groups.google.com/forum/#!forum/boosthttp-dev
Bedeho Mender
@bedeho
thank you so much! continued luck, looking forward to see your contribution to as part of boost and standard lib some time in the future
Vinícius dos Santos Oliveira
@vinipsmaker
thanks =)
Bedeho Mender
@bedeho
@vinipsmaker we have been trying a bunch of different frameworks, but we cannot find a suitable alternative, we are coming back to Tuafo and trying to see if it can work for us.
could you perhaps give us some indication about why you think boost asio+coroutines support is better than Tuafo?
Vinícius dos Santos Oliveira
@vinipsmaker
hi @bedeho
there are several reasons why I think Boost.Asio is better as a building block for foundation libraries
One of the reasons is because of the choice of active style (proactor design) instead passive style (reactor design). However, I don't have time to discuss this right now. I'm doing a blog post about it though and it'll be published eventually.
This is also related to robustness (avoid many more races)
And also related to testability (Boost.Asio has much more compreensive tests than Tufão and the reason is because Asio makes it easier to write such tests)
Another point why I think Asio is superior is thanks to how it is just much more flexible than everything else (you can use coroutines, callbacks, futures, blocking APIs and so on)
And coroutines aren't always the more appropriate choice (sorry if I let you have this impression).
Vinícius dos Santos Oliveira
@vinipsmaker
As an example why I like coroutines so much. There is this project I'm working on recently and we were told to rewrite a blocking library to be async. 27 lines turned into 189 lines in a mess that only coroutine have saved us: https://github.com/maidsafe/crust/pull/715/commits/3a1740664bd6306a0d4c0b04a6b5a22ecfd0a1cd
I'll have more time to talk later. You'll have to do your own research for now =P
Bedeho Mender
@bedeho
thanks for the comprehensive response