Re: Issues of state (was: Tkinter or wxpython?)
- From: claird@xxxxxxxxx (Cameron Laird)
- Date: Thu, 9 Aug 2007 13:37:41 +0000
In article <7xfy2t8l5n.fsf@xxxxxxxxxxxxxxxxxxx>,
Paul Rubin <http://phr.cx@xxxxxxxxxxxxxx> wrote:
claird@xxxxxxxxx (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.
.
- Follow-Ups:
- Re: Issues of state
- From: Steve Holden
- Re: Issues of state
- References:
- Re: Issues of state (was: Tkinter or wxpython?)
- From: Paul Rubin
- Re: Issues of state (was: Tkinter or wxpython?)
- From: Cameron Laird
- Re: Issues of state (was: Tkinter or wxpython?)
- From: Paul Rubin
- Re: Issues of state (was: Tkinter or wxpython?)
- Prev by Date: Re: Help with Dictionaries and Classes requested please.
- Next by Date: Re: tests
- Previous by thread: Re: Issues of state (was: Tkinter or wxpython?)
- Next by thread: Re: Issues of state
- Index(es):