A very good explanation. I think I get it now. In the bad ol' static
webpage days, a webserver's job was to figure out the mapping from the
requested url to the static file and then send that file back. Later,
dynamic webpages were created "on the fly" by processes which were fed
request parameters from incoming url requests: often these processess
were started and stop with each request.
I had thought that now in these modern days, with python, apache,
etc., that there was now some mechanism to keep the processes running,
and just feed requests to them and have them answer back their
responses, rather than starting and stopping a process (from a perl/
python/etc script). I think that J2EE offers this, no? I worked on a
(Tandem) mainframe a decade ago that offered this (albeit to the local
workstations: there was no WAN in their architecture back then).
That is, what you are describing is a system that maps urls to static
files or to python code in controllers et al, and uses a cookie to
transmit the key to the session file between the svr and the client.
Web2py pickles the session after every request and returns the cookie,
holding the id to the session, to the client - their is no stateful
process kept running or used.
I had thought it odd, at first, that the model was rendered with every
request (from the model files, processed in alphabetical order) in
order to provide the db global variable to the controllers, as I
thought that this was very expensive to do. But what do I know? I
haven't really tried to run any of this yet. Now I find that the
session info is saved and retrieved from a file (or else from a table
in the database) with every request. I guess it makes sense if its
purpose is to provide some "light" state info of the session. But I
may be abusing it, trying to use it to hold my datamodel/business-
logic-data-structures.
Hmmmm...
Maybe you could put #1 comment into the manual:
1) because clients ignore cookies this means there is a proliferation
of session files that are lost unless the xmlrpc server is told
explicitly to forget sessions. This means if one does not need
sessions one should use
def call():
session.forget()
return service()
2) should we provide a cookie aware xmlrpc cllient with web2py?
Err, xmlrpc is a light SOAP, no? SOAP does allow for stateful
connections, so why not xmlrpc as well?
3) should we allow other mechanisms to id sessions? For example a uuid
in the URL?
Is it possible for web2py to send the requests to another already-
running process and retrieve the answer? (Would this be like cgi?)
What about authentication then? Isn't a transmitted value/cookie
required in order to validate the credentials and permissions of the
request?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
