Request type's scope

[the-moisrex]

Top to bottom request type, or application level request type separation?

Currently, since we have things like cgi_request, the request type is top down and providing a common scheme for it is not easy because of all the extension system which means code duplication and introduction of type complexities.

Concerns

• Sub-App calling: even though our app might not need the full extend of the extensions, the sub-app that we need might require such extensions.
• App Pimpl idiom: separating the app interface from the implementation could be a big issue for some developers

Having codes like this, means that the sub-apps won't get all the cool features that the protocol-level request type might have.

One solution for this is to use a dynamic_request and the request type even inside the protocol itself.

[the-moisrex]

Another way is to provide a request type that knows all the parent protocol request types and when it sees those types, it can mimic their capabilities.

But that type would not be a sufficient type. We need request type to be known when the router's type is known in order to let the devs write functions that can utilize the context type which requires request type.

devs --require--> context type --requires--> request type --requires--> protocol specific request type.

Should we provide a protocol-independent http request type?

[the-moisrex]

A new idea is this: A dynamic request type that knows all the protocol's request types.

This means that the protocol (or app_wrapper) can check if the app accepts dynamic request type, then it gives the dynamic request type to the app, if not, it tries to give the protocol's original request type.