The latter seem to do with putting things into a BorrowBag.
And there's some cleverness so that an FnOnce can be used to process multiple requests.
My prejudice from Rack and PEP333 is that every request would start processing by entering a pipeline. At the bottom of that pipeline is a (New)Handler, which converts the request to a response (well, a result), which flows back up the the pipeline.
A router being the most signficant NewHandler in that scenario.
I'm not sure I agree with "makes sense for most pipelines"
We had a feature request issue a while ago that I'm coming to understand better: it's impossible e.g. to handle a 404 in the router this way.
One case that I'd love to build: a server for SPAs - so most 404s should get rebuilt as a request to /
The simplest fix here, I think, is just "decorate this NewHandler with this Pipeline" - which could apply then to anything.
And the current behavior would be "decorate all the routes of this router"
is that basically a complicated
route.on_error(StatusCode::NOT_FOUND, |state| /* build response */)?
since middleware's (at least right now and in my use case) usually modify the state before the handler or the response after the handler, but don't build responses
In Rack, the router is just a middleware - it chooses the next processor - which is often an app (handler analogue)
Very flexible compositions can result.
I've gotten somewhere on understanding pipelines-as-implemented.
(btw)
A) specifically, the pipelines provided to a router are effectively the "default" pipelines for each route. They'll be wrapped around anything that uses one of the
request family of route drawing methods.
This is different in behavior to being a wrapper around the whole router because there are several methods that allow you to route
_without_pipelines
The pipeline stuff gets a little more complicated - there's these
PipelineHandleChains which are BorrowBags so that we can ensure the lifetimes of the data in the pipeline definitions.
BorrowBags exist to make a collection of disparate things share a (longer) lifetime, right?
Where it gets weird is that a PLHC is a collection of Pipelines, which are themselves collections of Middleware,
(well... there's some
construct going on in there, and Pilelines -> PipelineInstances and NewMiddlewareChain -> MiddlewareChain but that confuses the issue)
When a pipeline gets
called during a request, we instantiate what amounts to a list of lists, and then do a depth first walk with the (state, request) pair, and then walk back with the result.
I mean really, it's all function composition, not list walking, and the weirdest part (which I'm still trying to get my head around) is how
PipelineHandleChains compose with MiddlewareChains since both convert a cadr-style list into function composition, with (state,request) running down the side.
Finally, I don't understand why it has to be, but the MiddlewareChain itself is declared
unsafe
So my primary research question now is: could the PLHC refer directly to Middleware - or some new middleware-type that's available to be implemented directly, but there's an adapter for old style Middleware
So I think it should be refactorable.
Unless anyone understands different?