At 06:31 PM 5/15/00 -0700, Bill Karwin wrote:

>Jim,
>
>You seem to be arguing against having a messaging capability in general.
>I'd like to offer an explanation of why I think this feature is needed.
>

I am arguing that a robust message capability is very difficult to
design. Although I'm perfectly willing to consider any serious
proposals, I think event messaging always boils down to abstract
event notification and event logs managed under transaction control.

>The current event mechanism allows a client to listen for a literal event by
>name, but that requires that the server function that posts the event to
>match that name. In the stock example, I can be notified that some stock
>changed, but not which one or by how much. Once I receive the event
>notification, it's time-consuming and inefficient to deduce the change that
>spawned the event.
>

In the stock example, sending the price change is less than useless --
by the time the client receives it, it must be considered stale. It
is tautological that any trigger posting an event can also post information
to a log table sequenced by a generator.

>Customers have often requested some sort of event argument mechanism, even
>if just a single value to indicate the key of the record that changed. An
>alternative is for clients to specify event names with wildcards, so one
>could listen on "Stock-*", a trigger could post "Stock-Redhat" and the
>client would receive notification along with the full name of the posted
>event.
>

Bill, I'm getting tired of saying the same thing over and over. Let
me do it again. The current mechanism is based on event count to avoid
race conditions, unknown latency, etc. I have never seen a network
oriented mechanism that worked any other way. The basic mechanism
works like this:

1. The program builds an event block consisting of a list
of event names and current counts. The block, a local
ast function, and ast argument is passed to the system.

2. When any event count on the server exceeds the event
count in the event block, an updated event block (same
events but updated counts) is generated and sent,
asynchronously, to the client. Note: it is possible
that an event that satisfied a client event block was
posted before the event block was received, in which
case notification is immediate.

3. The client compares the event counts between the original
event block and the updated event block to find out
what changed. The client can then use the updated
event block for the next cycle.

The basis of the mechanism is the ability to compare counts before
and after (the count represents the state understood by the client).
If you don't have the before count, which you couldn't in the case
of a wildcard, you can't detect a change.

>I realized that wildcards and simple event arguments were in a way
>equivalent. I also wasn't satisfied with that as a kludgey mechanism for
>passing additional information. So I thought an XSQLVAR structure would be
>more orthogonal with the client SQL interface.
>

A fundamental concept build into every fiber of InterBase is that
various subsystem should be able to share a database connection yet
remain functionally independent. That is why every interface object
is represented by a handle. A fundamental flaw in your proposal is
that your message queue has no context, no handle. If two subsystems
tried to use it, each would render the other unreliable. So you
have to add a handle to your proposal to management context. To
make that work, you have to add the handle to the existing event
notification mechanism. Then you have to build a mechanism to
synchronize the message queue with your handle at creation time.
This is really a problem. The current mechanism is initialized
with a event block of zero event counts, which returns immediately.
This does two things: it puts the event manager on notice that a
set of named events are interest to a client and returns the initial
current values for the event counts. The problem with your
mechanism is this: The initialization is also an event notification.
But if the event notification has an associated message, the message
needs to be sent. So, unlike the current mechanism where events
without a listener are dropped on the floor, event messages for
events without listeners must be retained indefinitely.

Talk about bloat.

Network synchronization is not a trivial problem. Inventing
a convenient API isn't a solution unless backed with an
implementation outline.

Jim Starkey