>The server knows there are n clients who have expressed an interest in the
>event 'blah'. Decrement n when any of these clients does one of the
>following:
>o Fetches the dataset
>o Asks to be removed from the notification list
>o Terminates its database connection
>
>When n reaches zero, discard the dataset.

Cool, I'm convinced!

I suppose the code that detects a failed client would also make sure to tidy
up the waiting events stuff too...

I agree that the existing event system should be left in tact and that these
more advanced "messaging" capabilities should be added in separately.

I'd like to see the ability to make the following distinguishments as well.

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. If the client has made the change it is already aware
of it and it doesn't need to respond to the event. Just the other app
instances that didn't initiate the change.

I think I've heard others want it to be able to post the events immediately
without waiting for the transaction to commit. So, have it wait by default
but include the option to tell it to broadcast without waiting.

I'd also like to see the messages actually defined like a table and handled
similar to a table. Take for example the case:

CREATE MESSAGE
TOMER_ORDER(
AORDER INTEGER NOT NULL,
AACTION CHAR( 1 ) NOT NULL
);

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...

If you examime the TIB_SyncCursor that is in the IBO library of component you will see that I already have this complete functionality existing. It works in conjunction with the DML caching mechanisms that I use. I just have to create the message table and use events in triggers of the message table to drive it.

It is very powerful and would make InterBase much more viable in a lot of ways.

Heck, lets patent the
"Active Table" concept because that essentially is what I am already
doing... Isn't that where you were headed earlier with using the standard
XSQLDA/XSQLVAR structures with the dsql_fetch() API call?

Harnessing the client side of an active table could be a little tricky. I
think that it would be wise to abstract the asynchronous nature of it as
much as possible. For example, have the client take care of downloading the
information ahead of time without waiting for the actuall fetch() call to be
made. Just have it in a buffer waiting for when the call is made. This would
free up the server more quickly. Then, just set a flag that the client can
have a thread poll or use an "event" that gets kicked off when the AST
routine gets hit with the notification.

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

InterBase will be the database of the new millennium.


-----Original Message-----
From: Bill Karwin <bill@...>
To: IB-Architect@egroups.com <IB-Architect@egroups.com>
Date: Monday, May 15, 2000 2:59 PM
Subject: Re: [IB-Architect] Event datasets RFD

>From: "Jason Wharton" <jwharton@...>
>> Being that events are not dispatched until the transaction is closed how
>> does one determine when it should be garbage collected? It isn't possible
>to
>> make it such that upon fetching because there are potentially many

clients

>> that would respond to the event.
>
>
>Bill Karwin
>
>
>------------------------------------------------------------------------
>Up to 60% OFF food!
>Buy Now and Shipping is Free.
>http://click.egroups.com/1/4016/4/_/830676/_/958427959/
>------------------------------------------------------------------------
>
>To unsubscribe from this group, send an email to:
>IB-Architect-unsubscribe@onelist.com
>
>
>