If your client is willing to pass a state token this can be used to retrieve the normal web2py session already by mimiking the cookie. This can be done already but I need to write some instructions.
On Aug 13, 2:34 am, rb <rbspg...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
