Can you expand on your proposal? It's not a big deal if, in the process of being wrapped, the application becomes a plug-in. Indeed, some thing along the line of Yii2 modules would be fine, as long as the entire application, except the part that parses the request, but at the least every thing that a designer of an application might want to offer, can be offered in the module. The wrapper must be an application, because it must replace the wrapped application, but why should we care that the wrapped application becomes a plugin? On the contrary, may be the concept of deploying an entire application was not a good idea to begin with. If the wrapper application uses a model to load the plugin and in this way we have the application as designed by the author, this seems great. In some frameworks, this would not be possible, because the wrapper, i.e., in your case, the application that uses the model to load the plugin, would have already loaded constants, libraries, etc. and we cannot load them a second time, but this might not be an issue with your proposal. Maybe, I do not understand what you propose.
The challenge in implementing the wrapper in web2py (without an extra HTTP request), as I see it, is that the wrapper needs to be a simple application, not a web2py application that conflicts with the wrapped application in terms of function definitions, etc. It is a challenge because web2py directly handles the requests toward web2py applications and we cannot map a request to a simple python application. We would have to rename gluon.main.wsgibase to gluon.main.wsgibase_wrapped and use gluon.main.wsgibase, not as a direct wrapper over gluon.main.wsgibase_wrapped, but has an handler that maps requests to a separate simple wrapper outside web2py, which will then call gluon.main.wsgibase_wrapped. We need this intermediary step, because we want that the location of the wrapper can depend on the request and be outside web2py. Anyway, this is just a vague idea. Perhaps your idea of using plugins is better. The current idea of Anthony is to directly use wsgihandler as the wrapper and change its location in the HTTP configuration. One problem with this idea is that the handler depends on the server, so if we change the server, we lose the wrapper. Apparently, this can be addressed. However, a more important issue is that the installer needs access to the HTTP server configuration, if he wants to choose the location of the wrapper. This breaks one of the requirements in the use case: the installer might not have access to the environment. My vague idea, if it works, does not suffer from these issues. Your proposal, if I understood it, seems fine too. On Wednesday, 22 June 2016 08:28:01 UTC-4, Carlos Cesar Caballero wrote: > > Hi guys, maybe I am missing something in the discussion, but, why not use > plugins to achieve that? you can write the "wrapper" code in a model, and > clients/users can install/remove/update it via the web2py plugin system. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
