Question re client/server and blocking

Bryan Olson fakeaddress at nowhere.org
Mon Mar 6 03:15:06 CET 2006


Frank Millman wrote:
[...]
 > There is a server component and a client component. All the business
 > logic is performed on the server.

Oh, what a give-away. If the logic is in the server, then the
client component should probably be the user's chosen web browser.


 > The client communicates with the
 > server via a socket. The server is multi-threaded - one thread per
 > connection.
 >
 > The server receives messages from the client, and responds as quickly
 > as possible. Sometimes it must respond by asking the client a question.
[...]

 > The server performs field-by-field validation - it does not wait for
 > the entire form to be submitted, but validates the data as soon as it
 > has been entered.

The modern way is to let the browser do the first cut at
validation and confirmation. Upon submit, the server
re-validates for security.

[...]
 > Now I have decided that, in some circumstances, I want the server to
 > ask the client a question before returning True or False - it could be
 > as simple as "Are you sure?".

Simple checks such as "are you sure" can almost always be handled at
the browser. Nevertheless, the problem you note is quite real...

 > This throws a large spanner into the
 > above scheme. Each caller cannot be sure whether the callee (?) will
 > return quickly or not, so it cannot afford to wait for a reply,
 > otherwise it may block. The only solution I can think of looks like
 > this -

Right. The server should go into a state where it can accept
the answer, among other things. Building interactive apps that
don't suck requires some sophistication in managing state.


-- 
--Bryan



More information about the Python-list mailing list