a bit of a late reply, sorry... Paul Rubin schreef:
> [EMAIL PROTECTED] writes: > > > I suspect he was trying to say that BaseHTTPServer has no mechanism for > > > handling state. As you know, of course, this is most relevant across > > > multiple successive connections to a server from the same client, and > > > has little to do with threads. > > Usually you would do that with browser cookies. > Mwah... Not if you want the client to be responsive to server-initiated messages, i.e. to implement some sort of listener ? (Or you should use Jason-RPC or some other relatively exotic tech?) And, and my guess is this is more applicable in the context of OP's question, not if you want to prevent constructing some client-representing object from a cookie-id for each incoming request (istd. of forwarding the request to a thread holding the client-representing object in the correct current state) > > Correct. My own 'brew' is multi-session-clients enabled (in fact I test > > with two applets from the same PC) but indeed I used confusing language > > saying 'client' for 'session'. > > > > Again: ThreadingMixIn doesn't give you 'session threads' in which you > > store persistent information - a candidate for some generic extension > > of SocketServer ? > > What exactly do you mean by session? <snap HTTP session trace> I mean (in a C/S context) : "A persistent state initiated by a client (e.g. a login- or first-message event) and maintained by the server." > > How many sessions took place here? Though trivial: 2 'TCP sessions' but I am (sorry for the confusion) not talking about TCP sessions but (and I guess OP too) application-level sessions. > It sounds like you want the answer > to be one session, that operations 2 and 3 are part of the same session. > But that makes no sense unless you associate them somehow, say using > a client cookie and a global session table indexed by the cookie. > In my world, message 3 would be 'session initiating'. Message 2 could be handled on the basis of a possibly changed 'client state' due to processing of message 1 (or other intermediate message exchange). > Why don't you take a look at any of the web frameworks that get > discussed here (Spyce, CherryPy, Zope, Django, whatever). They all > have mechanisms like that. BaseHTTPServer doesn't try to operate > at that level. The OP had a question about SocketServer not BaseHTTPServer? That certainly doesn't give you 'persistent state mechanism' for free. SocketServer doesn't either - all I wanted to say is I got myself confused a bit by the name "ThreadingMixIn" suggesting to me that it would give me a thread to store state info in - again it doesn't . I know Zope very well, and CherryPy a bit. At least for my project they wouldn't suffice because, as far as I know, they don't offer a mechanism for the server to 'raise an event' or 'send a non-response message' to the client. I don't know about Djange and Spyce but thanks: I'll certainly study them ! I suggested Twisted as an 'out-of-the-box' framework for state-persistent, real-time C/S framework but I perceived the overhead/learning-curve intimidating and decided to pass. -- T. www.phaedro.com Compile-time type-checking is a drag. http://www.bushclintonkatrinafund.com/ - help now but never ever vote republican again please -- http://mail.python.org/mailman/listinfo/python-list
