Issues of state (was: Tkinter or wxpython?)
claird at lairds.us
Thu Aug 9 15:37:41 CEST 2007
In article <7xfy2t8l5n.fsf at ruckus.brouhaha.com>,
Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>claird at lairds.us (Cameron Laird) writes:
>> Others have answered this at other levels. In elementary terms,
>> there truly is a difference, Paul, and one that's widely reified:
>> a "desktop client-server" application typically listens through
>> one socket, which therefore constitutes an index of the connection
>> or client, while a Web application communicates through a sequence
>> of independent HTTP transactions. The latter can manage state only
>> to the extent it passes session information around.
>Is this significant? In the case of a single user http app running on
>the same computer as the browser, the server should only listen on
>127.0.0.1. Every http hit then almost certainly comes from the same
>session. If there's doubt, the app can always set a random cookie at
>the initial screen and check that the cookie never changes.
>If there's only a small amount of session state (say up to a few
>hundred bytes) you can put it entirely into browser cookies and send
>it on every single http hit.
I'm not sure what we're discussing. Yes, I agree those are
mechanisms by which Web applications manage state. Apparently
we agree that, in a general Web application, state management,
or related persistence, requires *some* mechanism or assumption.
More information about the Python-list