> This discussion is challenging and it shows that you are right that use >>> cases are useful, if only to help frame a discussion. I think that your use >>> case is not to pass the configuration information, but the need for a >>> wrapper (for pre-processing and post-processing) >>> >> >> No, that is *your* use case/requirement. You began this whole discussion >> with the idea of passing configuration information but claimed what you >> really cared about was a "wrapper application." >> > > I was aware of that and I can see what happened in your mind - it's OK, > but very early I explained that the notion of application wrapper was > defined in response to a use case where we want to pass configuration > information under severe constraints, which included the extra requirement. > So, the definition of application wrapper included the extra requirement, > first implicitly, but as soon as needed, it was added explicitly with a > strong emphasis. So, this use case without the extra requirement is > definitively not mine. It is yours. I am not trying to diminish you or to > fight with you, but I know what was my use case, please. >
You may know what you were *thinking*, but all I know is what you have *written*, which is in direct contradiction to what you now say. Here is what you wrote previously: *It is related to the fact that the solution is a modification of how we connect with an HTTP server. If I move back the code on the rocket server, I lose the wrapper, because this modification is not implemented for this connection. With PHP, I do not need to change the way the connection to the server works. I could change the web server and it would still work in the same way. So, modifying wsgihandler.py is not totally what I want.* To which I replied: *To do this with web2py, we would have to wrap the application more directly. As already note, one way to achieve this would be to put a model file inside the application, maybe named something like __wrapper.py (the leading underscores to ensure it runs first). Any pre-processing code would go in this file. If you also need post-processing code, this file could set response._caller, which will wrap whichever controller action gets called. It would be easy to do updates in a way that avoids overwriting this file. I know this isn't your ideal solution, but I think the best we could do (without writing some complicated helpers).* So, my proposal was clearly a direct response to a requirement that you stated (not to have to modify wsgihandler.py). It had nothing to do with "my use case," and if you re-read everything, you will see that I describe no use cases of my own at all -- all suggestions I have made have been in response to requirements you said you wanted to meet. > I asked that we adopt the definition that includes the extra requirement > and I am still asking this. > I think you have two requirements that cannot simultaneously be met with web2py: (1) setting up the wrapper should not entail having to touch the web server configuration (i.e., modifying wsgihandler.py or having to enable a way to run it via the Rocket server), and (2) the "wrapper" code should be located outside of the application folder. I am not sure what you are "still asking," as we have articulated the various implementation possibilities. > So, I have obliged and attempted to identify possible solutions for you. >> Now you seem to be backtracking and claiming you really only care about >> passing configuration information, which is a very specific use case. >> > > Not at all, but it might be what you personally experienced. > Your words: *I think that your use case is not to pass the configuration information, but the need for a wrapper (for pre-processing and post-processing).* That's fine, but don't make it sound like I'm trying to push the idea of a >> wrapper -- that has always been your requirement. Please go back and >> re-read your own writing. >> > > Not interested. I remember the main flow. > My point is that if you were interested in passing configuration information, that was covered early on. Then you continued pressing for a wrapper application, gradually making your requirements more explicit. Anything I proposed was in response to your requirements (and I ultimately conclude that all of your requirements cannot be met). > You make it sound as if I have made general proclamations about the nature >> of innovation. We have not been having a discussion about abstract concepts >> related to new programming paradigms -- we have been discussing a very >> specific and concrete issue, namely the means by which you might do some >> pre/post-processing of requests. >> > > I was referring to the fact that, at many occasions, you explained that, > if a requirement does not have a real-world use case, it is unimportant. I > admit that it's me that brought in the notion of innovation to explain the > usefulness of abstract use cases. > You were pushing hard for a seemingly superfluous requirement, so I was simply requesting some motivation for the requirement -- some notion of *why *you would anticipate needing that requirement to be fulfilled. Partly to see if it is worth bothering to work on a solution, and partly to understand if we can come up with some other workaround that would satisfy your needs even if the requirement itself couldn't be met. > in web2py. My mention of "use cases" and "requirements" is limited to that >> context. >> > > Yes, I understood that. This is why, at one or two occasions, I asked that > we think in terms of forking web2py and, in this way, consider that we are > not in web2py anymore when we consider requirements. > You mentioned the possibility of editing your private copy of gluon.main.wsgibase for your own implementation, but you never suggested the idea of forking web2py to create a new framework (and indeed, your proposed edit would only work for your private implementation -- it would not be a general solution that others could use). > My point is that web2py seems to be able to satisfy the *use cases* you >> articulate (and probably many other related use cases) but not necessarily >> some seemingly unnecessary *requirements*. >> > > I certainly understood that it was your point. This is why I say that it > is your use case. > Your last sentence does not make sense. I offered no use cases. I offered solutions to *your *use cases, though concluded that we could not meet all of your *requirements* (some of which appear to be unnecessary). I simply argue that it is not worth putting in significant effort to meet >> those seemingly unnecessary requirements unless you can make a compelling >> case that those requirements are necessary and that the effort to meet them >> would be worth the benefit. You have not done so, nor even attempted to do >> so. You seem to think that merely by declaring a concept "abstract," it is >> necessarily important and therefore worth pursuing. >> > > Read my last post again. I explain that the reason we use abstract use > cases, without motivating them with real-world use cases, only motivating > them as a way to frame a discussion, it's because it's the best we can do > in a development process. > But "frame a discussion" for what? You offered no discussion about your requirements at all -- you simply stated them and claimed they were self-evidently important. That's not a discussion. > Furthermore, as already noted, "real world" does not mean "currently >> existing." >> > > In my last post, I covered that. In the analogy, it's the notion of > abstract car. It's an abstract representation of the (true) real-world. > BTW, perhaps you should revise your definition of "real world". > I just mean you can anticipate wanting or needing something, even if that is not the case at the moment. > Here is a quote from you (in response to the __wrapper.py idea): >> >> *However, if your objective is to be able to pass the configuration >> information and the installer can use the application folder, I don't see >> why they would not use it to achieve this objective, no need for a wrapper.* >> >> In other words, you were claiming that the installer could somehow "use >> the application folder" to pass configuration information in a manner that >> was different from the __wrapper.py idea. >> > > There was a "if" at the beginning of the sentence. You have to understand > the limited scope created by a "if". In French, we have the expression, > "With a if, we can put Paris in a bottle." > Yes, I understand the meaning of "if," but I don't know why you bring it up, as it changes nothing about the argument. Just put the words "if your objective is to be able to pass the configuration information," right between "claiming that" and "the installer could," and my point still stands. > Also, note that I never said the __wrapper.py method was a good solution >> for merely passing configuration information >> > > I never said or thought that you said that. Still, I wanted to say, if the > objective was as in my use case, your proposal is an overkill. > Yes, might point exactly. I told you from the beginning that an application wrapper was overkill for your use case. You insisted, though, that your use case didn't matter and that it was nevertheless important to have a wrapper application, so everything I offered in that regard was in response to your requests. Anyway, I think that's enough for now. Anthony -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
