Re: [boost] [http] Design ideas for a request router

Subject: Re: [boost] [http] Design ideas for a request router
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2016-03-15 13:29:02

2016-03-15 14:05 GMT-03:00 Artyom Beilis <artyom.beilis_at_[hidden]>:

> I say two things:
>
> Take a look what widely used frameworks do (Django, Rails, Struts) and
> don't look at NodeJS as
> major reference as it is way to new...
>

I think we're understanding each other now.
=)

Tree is much more intuitive to use and understand - if you want to
> start from something do it first.
>

So easy that I can already kind of imagine some implementations. On a more
serious note, I'll need to build one sooner anyway so I can see how I can
provide utility handlers (e.g. not_found_404) that would work on both
router styles.

You asked for an opinion? Right?
>

Yes, and I apprciate you're spending your time to evaluate my designs.

What is context of http::static_router::done() what it does?
>

For now it does nothing. The drafted router is very artifical right now.

Thanks to Boost.Http exposing a socket (which follows Asio active style a
lot) you need to explicitly ask for the next request. This responsibility
is part of the handler, but the router intercepts the handlers (and it may
be no viable handler). Therefore I thought it should be part of handler.
However the router needs to know when the reply is done so it can ask for
the next request.

I'll know for sure later when the router is less artificial.

Where is the context? What is request? What is response?
>

The context should be socket + input message. I'd like also to pass the
reply as an object to the handler. Therefore I hope the handler to have a
signature close to `void handler(Socket &socket, input_message_t &request,
output_message_t &response)`.

See having lambda for some router is cool but usually you need
> something more heavy - some context, session, request, response
> at least in general some class that does useful stuff with data.
>

Agreed.

This stuff can be embedded in the message. I plan to make the declaration
of the message type something easy where you select what you'll need.

Think of a backed that handles data, for example how do you
> implement http://www.todobackend.com/
> With multiple threads or event loop, with some stuff that actually
> does useful thing?
>
> I don't understand from you sample how stuff is connected to each other.
>

A big part is my fault because I haven't put much documentation/comments on
this prototype.

For now it is not connected yet. It's just exposing a router that takes a
string and choose a handler.

This todobackend project looks an interesting thing I should take a look
on. Thanks.

Don't get me wrong - you are doing nice stuff - but please Keep It Simple
> and Clear. Don't force yourself to fancy paradigms that may be useful but
> aren't common.
>

A simple example is still missing indeed. It was one of the most important
complaints in the last year review. I'm working on it (an existing router
is better than no router).

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/