I had almost the same problem with flash. Put this in the db.py to connect the session.
request.cookies[response.session_id_name]=request.vars.mysession_id session.connect(request,response) Then just send the session with pagename.html? mysession_id=178648217648721... /R On Aug 13, 12:11 pm, desfrenes <desfre...@gmail.com> wrote: > There have been countless flamewars on this subject... we need another > one here ;-) > As you guess, I think 3) is the way to go (although it doesn't have to > be limited to crud operations). I tend to trust Thomas Erl here > (http://www.soaprinciples.com/service_statelessness.asp). > Me and my team use json-rpc, which is pretty much the same as xmlrpc, > and most methods require a token, used only for auth ("can this client > use this method ?"), no state is kept on the server. We also consume > SOAP services that are not designed following the stateless principle > and it's a real pain in the... we even have to call methods in a > particular order just because they're not autonomous :-/ > Of course you may have different needs but since they don't seem to be > covered by the xmlrpc protocol, you should probably address them in > your application. It shouldn't be too difficult to pass the cookie > value in the url, or as a parameter and then find the session data on > web2py side. > The problem is that there's no real standard for this, so any > implementation in web2py will probably remain web2py-specific. It's > probably ok, if it's not activated by default. > > On 13 août, 09:34, 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 -~----------~----~----~----~------~----~------~--~---
