<giggle> That could be one way of interpreting it. But I was referring to an attribute that I had added to session - thus it was my session attribute. But with the very next request I found the session attribute gone. Thus I whined "wherefore art thou, oh session attribute."
Desfrenes points to an article, by Thomas Erl that begins: "The management of excessive state information can compromise the availability of a service and undermine its scalability potential. Services are therefore ideally designed to remain stateful only when required." To which I have to respond: "of course." *Exessive* state information would _never_ be a good thing. But what is "excessive" ? And he says that services should remain stateful only when required... Who is this guy? The Minister of the Obvious? <giggle> The power and beauty of pushing the business logic out to the client is that it leaves mostly stateless db access on the svr. Being stateless makes for easier (dynamic) configuration of svr resources, better scaling, and it makes maintaining the codebase simpler. However, there is a cost to pushing the business logic out to the client. Firstly it means that the client has to have more horsepower. If the client is a pc then it's probably not a show stopper - but it also means that deploying your app out to smaller netbooks, or smartphones, is gonna have problems. Albert Einstein said it was best to makes things as simple as possible - but no simpler. Pushing the business logic out to the client can lead to great problems down the road when query access (or some other kind of access) is needed to be granted to other devices or other web services that are acting as a client of our service. The point is that access to the web app must come through the business logic, and this constrains either the svr or the choice of clients. I don't think there is any one answer for all situations, but I am persuaded that the best choice is the one that moves data around the least, and centralizes the activity that defines the app or service, and allows for the leanest client. Of course, these are competing goals, and my bias would be to prefer a #3 solution, as well, unless specifics overruled. >There have been countless flamewars on this subject... we need another one >here ;-) There is nothing new under the sun. (And "gee" does it have to erupt into a flamewar?) Further to other points made on this thread, I ask the question: what about support for communication (rpc, or other) living processes? No one would suggest that the web2py web server start adding statefulness in order to provide such to specific applications, but why can't it be made to support shuttling web traffic between distant clients and local (stateful) processes? On Aug 13, 1:14 pm, weheh <[email protected]> wrote: > To add some levity to this important topic, rb is also, unfortunately, > confused about the meaning of "wherefore art thou, oh session > attribute?", which I believe him as asking where is the session > attribute, but in reality, it means, more approriately, "why and for > what purpose is the session attribute as it is?" --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
