Feature Proposal: Raxx.Context about raxx

[CrowdHailer]

I'm of the opinion that it is something we definitely want to do.
Having middleware without this just makes middleware unviable.
The reason being that something like an authentication middleware definitely requires being able to pass information to the controller.

That said I think in most applications one or two standard middleware will be all that's required. i.e. I don't think the average project should be defining many/any middleware.

The protocol upgrade stuff is interesting but I don't have anything useful to add. I'm not even sure it's worth giving much thought until someone tries implementing websockets or similar (if similar even exists, Is there anything like websockets but not websockets?)

My current goal is to go through the list of middleware that it would be nice to have (it exists on the raxx_kit proposals board) use the Process dictionary as need be and see what falls out.

The way I see it there are two questions

• structured/unstructured for the data
• Process dictionary or parameters for passing around.

I am leaning to process dictionary because if a middleware doesn't need to do anything with the context. For example imagine the following stack

Raxx.Session
MyNewMiddleware
Raxx.Flash

The flash middleware will need a few things from the session middleware, and the session middleware will need to know what was added/deleted by the flash middleware in the response.
Using the process dictionary allows MyNewMiddleware to be oblivious to the fact a context even exists

[nietaki]

I thought about it some more and I am starting to believe putting it in the process dictionary is the way to go. Adding it to the behaviours would complicate them a fair bit, without much benefit in most situations.

You're right, probably not much point trying to fit in protocol upgrade at this point.

The implementation should be simple enough, the bulk of the task is going to be providing a good API for it. I think it makes sense for me to build up a PR with some working implementation and we can discuss the interface based on it.

[tsloughter]

The problem with the process dictionary I've hit with context is propagating to another process when needed.

For now I've simply gone with providing both options, process dictionary context or variable context. If you use the pdict context and want to propagate you must get the current context into a variable and pass it as part of a message.

Personally in the case of middlewares like this I'd go with a variable. We've discussed doing this in Elli and it is the way I do it in grpcbox.