I am restating the use case and the concept of wrapper application. On Wednesday, 22 June 2016 09:00:12 UTC-4, Anthony wrote:
> > 1. I don't think this approach completely satisfies Dominic's > requirements, as he wants the wrapper to be external to the application > folder of the wrapped application (I don't think this is an important > requirement, but there it is). > > This requirement comes from an extreme use case where the author of the application needs full control over the application folder because he might need this space in an unpredictable manner and the installer needs full control on where the configuration information is stored, because he is a fanatic or some reason we don't know, something we cannot control, but yet he might not have full access to the OS. We need a space that is acceptable for both. It is a challenge, because the installer cannot use the application folder and the author cannot pick a location outside either. The wrapper application was the only solution that came to my mind. It works because the author does not have to know that location. In this context, came the need to define what exactly we mean by a wrapper application. We know what property is needed, but it will be nice to define what is a wrapper application by itself, independently of the use case. This was not done, but we know what it is naively. It's an application (most likely in the same language as the wrapped application, but not necessarily in the same framework) that will respond to the same requests as the wrapped application, replacing it, will do some little work and call the wrapped application, receive the response and, perhaps after some little modifications, will return it. Clearly, we have to add the requirement that it must be easy to define it outside the wrapped application in a robust manner, just like any other application. In the context of a framework, we could cover this use case in a completely different manner, because we have access to the folder of the framework and, as the author of the framework, we might decide that we will reserve a space for application configuration. In fact, it may be informally a solution adopted in web2py. On the other hand, we should be interested in an approach that covers even a more extreme use case where people can fork web2py and we do not know their need and they might want that the forked web2py folder is fully available, just as in the case of the folder application. In this picture, web2py plays the role of the application to wrap. Regarding the comment that the flexibility to have a separate wrapper is not important, as I said to Dave, presenting this wrapper application approach to someone that is currently using a framework and have happy customers in terms of how to configure the applications would be inadequate. It's only useful as a way to analyze different frameworks when you are thinking about building a new approach, perhaps with the perspective of an easier integration of code from different frameworks, forking, etc., i.e., for reuse of code, etc. At this stage, it makes sense to consider these extreme use cases, even crazy ones, because it can only make your approach better. I am hoping to find people that also find this interesting and perhaps find another perspective why it is useful that what is deployed, even what is intended to be a full application, has to be wrapped. -- 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.
