2016-03-14 17:10 GMT-03:00 Artyom Beilis
Take a look what I do in CppCMS with URL mapping.
I will. Thanks for the advice.
I thought I could combine and allow both styles. Actually, Boost.Http don't
force you to use any style and both could be used.
I suggest do ONE thing but do it well.
I'm not building a megazord application. There will be many of them and the user will choose what it thinks it fits better. It's not like other frameworks that create a megazord class that will be its own executor containing its own thread pool being its own request provider and request router and so on and so on.
concerned about performance. Therefore, many may not like the std::function<> approach. It can imply some hidden allocation that you
Knowing this is Boost and Boost is about serious C++ users I know I must be pay
even if the handler is not going to give up on the route.
Negligible - you should create routing + callbacks at the application start so it does not matter how much std::function allocates as long as you don't copy it on each request.
For now I'm discussing the "chained style" and in this style the "next" argument will be passed around and around (it IS being to be copied). It's not like something that would be done at application startup and not modified again. Anyway, I implemented the "next" more like a search index than a type erased generic functor.
Another approach would be to turn the handlers into template functors.
However, this would be too much burden on the user.
Please don't... Think about end users and compilation times.
I don't like this approach either. I'm just mentioning it.
Other APIs use a passive style and constantly check if there is network
activity and schedule new socket reads. Boost.Asio is more explicit and Boost.Http follows along. An active style is useful because it'll allow you to defer new operations to later when your server is under heavy load. Anyway, I felt that maybe I'll need a "done" function and I've added an empty one for now. I'll see if I'll really need it later when I integrate everything together. For now, just know that the "done" function does nothing.
See... it is nice to have defer functionality for stuff like server-sent-events or another hip called web sockets.
But vast majority of web api/web work need to do stuff synchronously...
In no way I'm gonna remove flexibility. It's easier for you to see me implementing two interfaces (a "lower-level" and a "higher-level") than you seeing me making the API less useful (i.e. usable in less situations).
algorithms that adapts rules and conditionally call your handler or
- The router doesn't take the rule, only the handler. Later, I'll make pass
the route to the next handler. This design is more flexible and I wish I could also use it in "tree style too".
I don't understand but sounds like bad idea - when you build routing tables it should be clear what path is mapped to what if you separate it in the code it would be messy
It is more like:
static_router::make
DISCLAIMER : I'm THE author of CppCMS [1] high performance C++ web framework
And I'm glad I caught your attention. I may add that I'm a fan of the work done with the benchmarks of CppCMS: - http://cppcms.com/wikipp/en/page/benchmarks_php - http://cppcms.com/wikipp/en/page/benchmarks_all I also remember seeing other nice things like "taking cache to its limits", but it has been so much time since the last time I took a look. -- VinÃcius dos Santos Oliveira https://vinipsmaker.github.io/