Lane Stevens wrote:
It was my understanding that xmlrpc is stateless, and so I had supposed that sessions being stateful would not be supported. I had hoped that there was a way to tie to sessions. I assume that there would need to be a transport mechanism of some sort to deal with sessions - but that is just a guess.
Yup. xmlrpc is stateless, like http is stateless.
Related question: Is there a best practice for dealing with state in the use of web services through xmlrpc?
(Vague) Use case: I have a Zope application that carries some information from previous transactions in the session, and some methods that have depended upon that information being present to produce valid results.
I am creating new methods or changing existing methods and prefer writing tests in xmlrpc rather than as page hits - or as method calls against an offline instance of Zope. In the case where these methods depend upon something that expects session data, I have resorted to page hits.
I don't know if there is a "best practice" for this. It's possible in straight xmlrpc, but you probably will not like it. If you look at the sessioning API, you'll find methods to get the browser id name (usually "_ZopeID" in a default session) and browser ID. This is the session hook, and zope looks in the REQUEST (form data and cookies) for e.g, {'_ZopeID': blah}, and uses the session named 'blah' as a dictionary for the session data as needed. So, for pure xmlrpc, you would 1. Make an initial request to setup the session, 2. The session hook is added somehow to the xmlrpc payload for each request and response. 3. Since xmlrpc does not have named parameters, zope probably will not find '_ZopeID' in the xmlrpc POST from the client, so it is up to you to do an extra step to unpack the xmlrpc POST into something zope sees as a session id. 4. Set '_ZopeID' in REQUEST, before touching session data. Otherwise, you will create a new session. 5. Access the session data in the usual way. So, pure xmlrpc sessions are ugly. It probably requires rewriting each method (and the client) to handle this. And this is probably not what you want to do. I were doing this again (I'm remembering as I go), I would set and use a cookie with the session info (zope tries to acquire a cookie automatically as soon as you touch a session), and make the client return the {'_ZopeID': blah} cookie with each request. Does your xmlrpc client send cookies? This is what I would recommend. -Jim Washington