Application router

[practicingruby]

A lot of complicated issues arise from having only a single linear path to mount applications in. We need either a horizontal mapping at the top level, or a composite application router that could be dropped anywhere within the linear chain.

Top level horizontal routing:

request -> router ---> app_a---> response (if matched)
                  |
                  ---> app_b---> response (if matched)
                  |
                  ---> app_c---> response (if matched)

Composable router application. This seems more promising and logically easier to think through, but retains the "one request, at most one response" limitation. Still have not figured out whether that is going to really harm Newman's usability for scenarios we're interested in.

request --> (pre apps) -> router_app--> component_app_a----> (post apps) -> response
                                      |                    |
                                      > component_app_b----^
                                      |                    |
                                      > component_app_c----^

[practicingruby]

@ericgj I want to try the "Router as an application composed of other applications" approach. What do you think?

[practicingruby]

Note... Newman::Router needn't necessarily be a Newman::Application, just something that responds to call()

[ericgj]

Yeah, the composable was what I was thinking to try first, it doesn't break the way the server works now since it's just another app. But not sure this is a priority until we get some more real multi-app scenarios going.

On that note, I did put up a semi-working scheduler app if you want to take a look. It's designed to work with a mailing-list app downstream, as a kind of mailing-list "add-on". Mailing-list archives functionality could be similarly done - as a separate app. But there are various complications about sharing pstore and settings files among apps.

[practicingruby]

I want to address the router simply because I feel like it's one of those problems that if there isn't a good solution in the framework for it, there will be ten different hacks downstream. In general I definitely want to take a use-case driven design, but I think this qualifies as one of the foundational features.

I'll look into whether these ideas could map onto scheduler or archiving. I'm thinking this router feature is one to consider for 0.4.0, as it's important but not urgent. So we have at least a few more weeks to think about it.