> Furthermore, a "good" service should be designed to work > with no state. State is the client's job, not the service, and this > makes your service more scalable.
An n-tier (web) app has at least a database facility, business logic facility, and presentation. Your comment above implies that all business logic should exist in the client - and not in the svr, because only trivial business logic is stateless. I don't think this is necessarily true. The choices really boil down to three: 1) put stateful business logic in the svr, keep it active, and pass a session token between client and svr (ie keep the state active in the svr); 2) serialize the business logic state to disk (or cache) and then throw away the state, and reconstitute the state upon each following client request in the session (keep the state in the server but unserialize and serialize it with each client request); 3) keep the business logic and its state (active) in the client and only send stateless CRUD back to the svr. I see advantages and problems with all three approaches. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
