At 10:20 AM 5/17/00 -0700, Jason Wharton wrote:

>
>Then, instead of having a new post_message command you could simply perform
>inserts into the message table as you would insert into any other table.
>
>A SELECT statement could be prepared to determine the client's interest in
>events. A WHERE clause could be used as a filter.
>

Some questions:

1. How do you wait for a message?
2. How do you wait for messages from a number of message tables?
3. What happens to a result set when another message appears?
4. Could you explain what the server does in response to an
insert into a message table?
5. Can a message table participate in a join? Can it be ordered?
Can it be referenced in a stored procedure? Can it have
triggers?

>
>This will of course add an additional case everywhere that tables, etc. are
>dealt with so the changes would be quite pervasive throughout the engine but
>it would have the benefit of meshing in with all of the existing code,
>logic, etc. to be immediately put to practise. I think this would require
>the least amount of learning for the user-developers as well.
>

Let me say this gently. Designing a feature so it can be implemented
by somebody who doesn't know what he is doing is not a goal. The class
of mechanism that we're discussing will require in-depth knowledge of
the engine, the remote server, the remote client, the protocol, the
idiosyncracies of various TCP and LanMgr stacks, threading behaviors
on all supported platforms, and signal handling warts on non-threading
platforms.



Jim Starkey