Precisely, using all that middleware in custom wsgi.py scripts gives you a lot of power. Declaratively configuring few middlewares in an app that will use them upfront is feasible (trytond does!). Creating a config system that will power the setup of arbitrary middleware feels like designing a programming language to me. That’s why I’d fallback to wsgi scripts.
I don’t want to dicourage you from taking that path. I just wanted to state that is is full of pitfalls while the wsgi.py path will always be there, will always be easier, will always be more powerful, and I find no reason to regret abusing it.
Furthermore, if the trytond binary was to load aribtrary wsgi scripts with a cli/config parameter, it would instantly gain all that power “for free” instead of designing such a config system. Otherwise gunicorn is already a solution for that, but a framework-specific toolchain is always an interesting feature.
Said this, I think this thread has reached an off-topic status. Should we open a new discussion linking what has been discussed here?
Request language could be inferred from the very request, which will be accessible. It will be in the context of a RPC client call or it could be in HTTP headers if a browser was consuming a user application. In the worst case, it will be in a per-user record in the database but potentially stored in a cache. Maybe every operator will have to settle for a different heuristic but I believe it is feasible.
Next week I’ll check out those features because I feel like I am missing your point.
That looks promising. Yet I still can’t imagine how each server would tell sentry-powered clients the DSN where to report events. Should it be a per-client configuration instead of per-server? How is a plugin distributed and configured if not manually? How a server tracks which clients have what plugins? I must admit this feature was never in my short-term plans.