Normally when you visit a web page web2py creates a session, stores
the session in a file and associates the file to a session id. It
sends the session id back to the client in a cookie.

When the client makes other requests, the clients sends the cookie
back and the server can retrieve the proper session from the file. The
cookie is what allows the server to identify multiple requests as
coming from the same client.

This works in the same way with XMLRPC except that normally clients
ignore the cookie. So web2py does not have a way to recognize whether
two RPCs come form the same client or not so it assumes not. This is
because there is nothing about sessions in the specs of the XMLRPC
protocol.

One think you can do is the following:

from gluon.storage import Storage
rsession = cache.ram(request.client,lambda:Storage(),3600)

and use rsession instead of session. The different is that rsession
wil store session in ram (not disk), will expire (3600 seconds), and
will identify clients using their IP address instead of the cookie. If
you expect many IP to connect via XMLRPC this may cause a memory leak
since rsessions are never really deleted.


Massimo


On Aug 12, 1:14 am, rb <rbspg...@gmail.com> wrote:
> Thx kindly, Massimo. I'll check the links out... but...
>
> >Once more, the issue is not with web2py. The issue is with your
>
> client. It does not support cookies, hence it does not support
> sessions.
>
> Errr... no, that is not the issue that I'm pointing at. If "sessions
> remain and do not expire" means that in between accesses the session
> global variable is pickled to the disk and then later reconstituted
> from the disk or else pickled into cookies and sent to the client,
> then I have a problem with this definition. I don't think my data is
> necessarily pickle-able.
>
> I guess I misread/misunderstood paragraphs like:
>
>    The option masterapp=None, by default, tells web2py to try to
> retrieve an
> existing session for the application with name in request.application,
> in the
> running application.
>
> to imply that there remained a *running process* that kept the session
> variable (and hence my data) instantiated in between calls. I'm new to
> this web app thing.
>
> So, thx for the clarification. I'll either try to hack the code you
> referenced or else I'll just end up using the web2py server as a data
> server and keep the business logic in the thick client.
>
> ---
> Rb
>
> On Aug 11, 10:39 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > Correction. You must use this 
> > client:http://code.activestate.com/recipes/501148/
> > not this client:http://fotinakis.com/blog/blog/2008/cookies-xmlrpc-and-ssl/
>
> > Massimo
>
> > On Aug 12, 12:19 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > Once more, the issue is not with web2py. The issue is with your
> > > client. It does not support cookies, hence it does not support
> > > sessions.
>
> > > If you use this client they should work:
>
> > >http://fotinakis.com/blog/blog/2008/cookies-xmlrpc-and-ssl/
>
> > > Massimo
>
> > > On Aug 11, 7:31 pm, rb <rbspg...@gmail.com> wrote:
>
> > > > Well I need more than just cookies. I can't serialize the app
> > > > inbetween each call. I need a working process, which has active data
> > > > structures (database tables, dictionaires, etc).
>
> > > > Is there anyway for an app to talk out through web2py to a client?
>
> > > > I had (incorrectly) understood that sessions stick around and remain.
> > > > Even if a session object is cookized in between calls doesn't the docs
> > > > say that the session stuff remains? The manual says:
>
> > > > ===
> > > >   4.8 session
> > > >  ------------------
> > > >            is another instance of the Storage  class. Whatever is
> > > > stored into session for example:
>
> > > >  session.myvariable="hello"
>
> > > > can be retrieved at a later time:
>
> > > >   a=session.myvariable
>
> > > >   as long as the code is executed within the same session by the same
> > > > user
> > > >   (provided the user has not deleted session cookies and the session
> > > > did not
> > > >   expire). Because session is a Storage object, trying to access an
> > > > attribute/key
> > > >   that has not been set does not raise an exception, it returns None
> > > > instead.
> > > > ===
>
> > > > Thus I can store myvariable into session and retrieve it at a later
> > > > time. What the manual _should_ say, if I understand you now, is that
> > > > the global variable "session" is pickled between each call into a
> > > > cookie and unserialized with each subsequent call. If your protocol,
> > > > eg xmlrpc does not use cookies then you can forget about sessions
> > > > being used to store info to be retrieved at a later time.
>
> > > > Argh! This is upsetting. I was thinking that session (and some
> > > > pythonic process) remained running in between calls. Argh.
>
> > > > Thx for the link, I'll check it out. (fingers crossed)
>
> > > > ===
>
> > > > On Aug 11, 4:22 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > This is not a problem with the server but with the client.
> > > > > You may try the cookie aware xmlrpc client proposed here:
>
> > > > >http://code.activestate.com/recipes/501148/
>
> > > > > Or you need to pass an extra key to the function calls and is that to
> > > > > retrieve a session.
>
> > > > > Massimo
>
> > > > > On Aug 11, 6:09 pm, rb <rbspg...@gmail.com> wrote:
>
> > > > > > Further, I added a :
>
> > > > > > session.hello = "hello, world"
>
> > > > > > in order to see if it just didn't want to hold onto MY data. No 
> > > > > > dice.
> > > > > > session.hello is gone on the next call as well.
>
> > > > > > ---
>
> > > > > > On Aug 11, 3:02 pm, rb <rbspg...@gmail.com> wrote:
>
> > > > > > > In my think-client xmlrpc protocol to web2py svr code I am trying 
> > > > > > > to
> > > > > > > maintain data in the session global variable but it doesn't seem 
> > > > > > > to
> > > > > > > hold it. For example I first start by creating a document-form 
> > > > > > > (tree
> > > > > > > of datatables), cached in a data structure, as an attribute of
> > > > > > > session. Here's the code:
>
> > > > > > > from gluon.tools import Service
>
> > > > > > > service = Service(globals())
>
> > > > > > > def call():
> > > > > > >     return service()
>
> > > > > > > @service.xmlrpc
> > > > > > > def xrBeginDocFrm( frmName):
> > > > > > >     ''' create table records and push xrInitRecord down to all 
> > > > > > > tables.
> > > > > > > '''
> > > > > > >     if session.frmz == None:
> > > > > > >         session.frmz = {}
> > > > > > >     if not session.frmz.has_key("frmName"):
> > > > > > >         session.frmz[frmName] = rna.DocFrm(db, frmName)
>
> > > > > > > Then later I call the svr to get the table column definitions:
>
> > > > > > > @service.xmlrpc
> > > > > > > def xrGetColDefs(frmName, tblInstName):
> > > > > > >     tblInst = session.frmz[frmName].GetTblInst(tblInstName)
> > > > > > >     return tblInst.GetColDefs()
>
> > > > > > > but I find that session does not have a frmz attribute. I can 
> > > > > > > walk the
> > > > > > > debuger through the svr code so I can see that the functions are
> > > > > > > getting called, but when I inspect session it contains nothing.
>
> > > > > > > I thought sessions stick around forever? I thought that session 
> > > > > > > was
> > > > > > > the place to keep my own attributes that will live on (between 
> > > > > > > xmlrpc
> > > > > > > calls).
>
> > > > > > > Heeeeelp!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to