From: "Jason Wharton" <jwharton@...>

> I suppose the code that detects a failed client would also make sure to

tidy

> up the waiting events stuff too...

I assume the current InterBase product does a similar thing already, to
clean up query result sets when a client goes away (whether by a proper
disconnect or by catastrophic dropped connection).

> I agree that the existing event system should be left in tact and that

these

> more advanced "messaging" capabilities should be added in separately.

Okay. My original idea of extending the event mechanism was that the old
behavior would still work as it used to. If one simply used the traditional
POST_EVENT 'foo'; then no result set would be stored, and no fetch of the
message would be required.

But as Dave put it, the message-passing mechanism is really suited for a
different purpose and should be separated syntactically and semantically.

> Broadcast to all connections and optionally ignore the one that actually
> made the request. This would be useful to manage the synchronization of
> datasets on a client.

Can't this be done if clients participating in the synchronization system
explicitly listen for the message? That way other clients (like a simple
isql session) wouldn't have to handle these broadcast messages.

I thought you were going to suggest that the broadcast message mechanism be
used for system-wide "shutting down" messages. That would be a useful
addition. Actually, it doesn't require a messaging mechanism, the existing
event mechanism would do it.

> I think I've heard others want it to be able to post the events

immediately

> without waiting for the transaction to commit.

What happens if the transaction rolls back? The clients are notified of a
change that never occurred. Just say "no" to dirty reads! :)

> I'd also like to see the messages actually defined like a table and

handled

> similar to a table.
> Then posting a message to the client would be like fetching the record...
> In truth, this could be thought of as a dataset on a client that

listens...

Yes, that was the purpose of defining an ephemeral XSQLDA for the result
set.

> have the client take care of downloading the
> information ahead of time without waiting for the actuall fetch() call to

be

> made.

I don't like this because it consumes network bandwidth (possibly a lot of
bandwidth) without waiting for an explicit request to do so from application
code. This is exactly why BDE is such a pain in the neck for client/server
operation.

Bill Karwin