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 -- http://mail.python.org/mailman/listinfo/python-list
