>Could you elaborate, please?

Gladly. It has been about two years since I've had any dealings implementing
them so I'm gonna be a little rusty.

>What problems did you find in using events?
>What were the nature of the flakes?
>Is the problem in documentation, implementation, or design?

Keep in mind I am in the Windows arena only... I think mostly my problems
were a result of implementing them in a non-native language and lack of docs
geared towards it.

First of all, it was quite difficult to harness the API mechanisms to handle
them. The docs were not clear at all on how to use them. It didn't help that
I was using Delphi either... Fortunately I found the IBEventAlerter
component written by James Thorpe and it showed me how to use assembler to
make the call with dynamic parameters. Not much else in there was very
useful as I didn't like the approach taken.

It also isn't clear if isc_free() should be called and how resources are
handled when cancelling and unregistering events. Does GDS32.DLL handle them
or do I need to explicitly handle them. Did I receive a handle that needed
to be deallocated or was it something else. Noting made that very clear to
me.

It seemed strange that I had to requeue them after a notification too. This
seemed like a potential problem but now that I understand the event block it
doesn't seem so unusual. It compares counts to determine if there has been
activity so there wasn't any activity missed between the previous
notification and the newly registered one. I also liked this because I could
defer the processing of events and they would just accumulate while I
waited.

There seemed to be different behavior for local and remote connections.
Sometimes you would get an immediate AST notification upon registering
interest in the events and sometimes you wouldn't. This complicated the
setting and monitoring of flags to know when an event really was generated.
Either you would get a bogus notification or potentially miss the first
legitimate one. Being an asynchronous environment this made it kind of messy
to tame these inconsistencies.

Other complexities I had a hard time with were due to the asynchroneous
nature of the events stuff which can't really be blamed on the design. For
example, if you are in the process of destroying your Delphi components and
an AST notification is received at the same time it was possible to attempt
processing an event with invalid pointers, etc. So, I figured out a way to
make sure dependant resources were still in tact. Otherwise, problems could
have taken place. In theory calling cancel_events should have been enough
but my testing proved that additional protection was necessary.

Of course then there are the outright bugs that have riddled events. In WIN
NT if you didn't have certain fixes applied the TCP/IP layer would fail to
respond to events. NetBEUI would work but then upon closing up you app it
would produce an access violation and lock up the system. Even lately there
seems to be a problem where now you get a CPU spike for 20-30 seconds and an
access violation when using the remote interface. It's just been a mine
field to use events and so I'm hoping that with future versions these
problem areas will receive more immediate attention and resolution of
problems.

The SuperIBEventAlerter has been no more insulated from these problems as my
IB_Events component has been either. I've done quite a bit to make IBO
handle events in spite of these problems and have even managed to take the
synchonizing them with the main thread to avoid problems people would walk
into using the other stuff. The IBEventAlerter would generate an event that
people would simply use as though there was no special need to synchronize.
That's where others have gotten into trouble with earlier implementations
with events.

I'm for keeping events as they are and introducing other more flexible
mechanisms to interact proactively with a client in an intelligent manner. I
think I've already expressed the details of my wants in an earlier thread.
Bill's ideas are getting right in line with things that I would like to see.

Most every need I have had for events has included a need for various pieces
of contextual information. Because of the lack of this information (more
than just data too) I have had to implement other means of getting the
contextual information that are clumsy and inefficient and impose
limitations of usage of application logins. Using "messages" would be an
excellent way to accomplish this especially if the existing structures are
utilized and contextual information is available.

FWIW,
Jason Wharton
InterBase Developer Initiative
jwharton@...

InterBase will be the database of the new millennium.