The problem space is in terms of wrapper applications. The original question is can we have a wrapper [without an http request] as we can in PHP?
I get the impression is that you plan on writing one application for use by many customers, and that this application will be installed in many environments. Your customers will do the installation and administration of the application *in their environment*, which includes installing updates that you provide. The customers may also be doing OS upgrades without coordinating with you. Is my understanding of the problem space correct? I have been pushed to explain the use case and finally the discussion was about this use case and the question became this use case. Yes, this is the use case. However, actually, if you read the original question, it is clear that it was not it. A question might have emerged from a practical use case, but then it stands on its own and we can look at it independently from a practical use case. So, my attitude was that the main subject of the question is wrapper applications and it is useful to connect this with a use case. Perhaps, the rule here is that a question should be how to address a practical use case with no attach to a particular approach. I would not argue against your rules, if there are such rules. In fact, I am indeed interested in that use case. Even from that perspective, though, I feel that the concept of wrapper applications can shed some light. In the one example I have of a major upgrade to one of my systems, there was no problem ... On occasion a new release of these applications will, indeed, overwrite the conf files, but replacing them with an archived copy is not difficult for the system administrator. These apps use /var/lib for the home of their code. The OS for this server has been rather stable, so I haven't seen what an upgrade does. I read carefully how you do things, including the part that is represented by "...". In a way, the concept of wrapper applications is out of place in such a context. When I say that it can shed some light, it is more as a tool to step back and see what is possible in an abstract manner. It can have an effect on how we do things. I do not think that you meant that there is no room for improvement, but how it happens and if it happens is up to the person who develop a practical approach. For me, thinking about concepts such as wrapper applications is like sharpening the knife, improving the abstract concepts, which are tools in developing an approach, but how one use the knife, the tools, is up to the person. There was some suggestions here that the use of wrapper applications is not a different approach. I don't buy this. It is possible that it does not help or is somehow equivalent to existing approaches. I suspect that it is not the case, but, if it is the case, it will be useful to clearly see it and the first step is to recognize it as a different approach. This is why I react when it is suggested that it is not different. As to how you could do a wrapper application in web2py, my first thought is ... just another web2py application, that redirects to the main application, is certainly a possibility. This app could be configured for the local environment, and append that information onto the URL being sent to the main application. This would allow the main application to be updated without having to redo the local settings, and it's as independent of OS upgrades as web2py itself is. Thank you to show that you understand the concept of wrapper application. Indeed, this is a way to create a wrapper that I did not think about. I hope that you see this as a different approach. Whether it is equivalent in some ways to existing approaches is a separate question, which I do not think is easily answered, but I might be wrong. Note, however, that this approach also requires an extra http request. It is an improvement over the internal HTTP request, because you can reuse the same tcp connection, but it is also much less efficient because the new http request is not internal - we have to go back to the browser. This is why I like the way it can be done in PHP with a simple include. I suspect that the same is also possible in web2py - no need for an extra HTTP request, but we are just lacking of imagination. This is the original question. I have been talking about the value of the concept of wrapper application to pass the config file location, but it was not my intention at all to discuss that. I just wanted to know if it is possible to do this in web2py as we can in PHP [without an extra HTTP request]. I do not complain. I appreciate very much what we discuss and I am sure we will find a way to wrap an application in web2py without an extra HTTP request. It just did not happen, because we did not focus on this and instead tried to argue that it is not interesting. -- 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.
