>In short, this is the ACTIVE table concept...

Let me just say that I already have this all built into IBO with the
TIB_SyncCursor component. I really don't mind if the complexity of this
entire model weren't moved into the server as I am able to deliver 99% of it
already.

As a starting point to polish up what I have I would just like a few
additional capabilites added and then perhaps we could put to rest the
entire messaging thing and just make use of the architecture that I have in
IBO built on top of events and message tables.

I don't think adding all this to the engine could be done significantly more
efficiently that the existing mechanisms allow it to be done anyway. We have
events and they fill the critical need of getting notificaton from the
server. We can handle the rest from there...

I use regular tables as message tables and simply put a POST_EVENT
"MYMESSAGE" in the AFTER INSERT trigger of it to wake things up as needed. I
use a generator sequence so that the client knows to only be concerned with
records subsequent to the sequence it has fetched up to. Then, on the client
I simply fetch the records I am interested in and store the sequence of the
last fetch to use in the input parameter the next time around so that I
ignore records(messages) previously fetched.

When I want to ignore my own initiated messages right now I have to use the
USER system variable but this means that for this to work I can only allow a
user to have a single instance of the application with their USER opened.
Otherwise, their additional instances will not receive the messages via the
TIB_SyncCursor.

Thus, I would like one of two things added to the server.

The ability to operate in a connection-context global variable space where I
can initialize, alter and read variable values by making a call to a routine
similar to GEN_ID() except that I declare my global variable definitions,
etc.

At the very least I would like the CLIENTID system variable I talked about
earlier.

The other capability I need added is a way to know when the last connected
user was logged on. This information could be used to keep my message tables
garbage collected if I could simply delete all records stamped prior to the
time that the earliest connected user of all live users was connected. Could
this somehow hook into the glogal variable stuff I was mentioning above?
Rather than bugger up the SYNTAX of the SP/TRIGGER language everytime a new
and useful system variable is to come along these could simply be accessed
through a common routine receiving the variable as a parameter kind of like
the GEN_ID() routine receives the generator name as a parameter...

Hope this helps...

Jason Wharton
InterBase Developer Initiative
jwharton@...

InterBase will be the database of the new millennium.