Tufão asynchronous web framework for C++/Qt | development and discussion | Mirror irc://irc.freenode.net/#tufao
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
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.
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
could you perhaps give us some indication about why you think boost asio+coroutines support is better than Tuafo?
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).
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
we are currently giving it a test run, seems to be working well for us thus far
we seem to be settling on Tufao now, it was quite managable to cross compile for windows, and it has solid documentation.
vinipsmaker hey
vinipsmaker this is the channel for the Tufão web framework
vinipsmaker https://github/vinipsmaker/tufao