<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?