Watch, Follow, &
Connect with Us
Public Report
Report From: InterBase/Server/Unsupported    [ Add a report in this area ]  
Report #:  4466   Status: Reported
Provide server event processing and related facilities
Project:  InterBase Build #:  0.206
Version:    7.0 Submitted By:   Cem Karacaoplu
Report Type:  New Feature Request Date Reported:  5/17/2003 5:34:18 AM
Severity:    Infrequently encountered problem Last Updated: 5/17/2003 8:10:32 AM
Platform:    Not OS or platform specific Internal Tracking #:  
Resolution: None  Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (4 Total Ratings)
4.25 out of 5
Total Votes: 3
Description
Present mechanism of events allows only clients to hear them. But the purpose of the event mechanism is to invoke an action somewhere. This should not be limited only to clients. These questions remain unanswered:

1. What if no client is listening at the time of event?
2. What if the server itself has to perform some tasks too and they are not suitable for a client?

Therefore,

1. events should be registered to an RDB$ table
2. there should be two fields for hooking stored procedures to the event. One for before_announce, another for after_announce
3. if the defined event occurs and IB finds a before_announce, it should execute it, and if the before_announce returns 0, then announce it (default behaviour) or else if the before_announce procedure returns non-zero it won't.
4. the after_announce part will anyway execute if hooked.

This will make externally defined events as elaborate as internal database events like before_update, after_update, etc.

It has many more advantages as:
1. there will be a central repository of events where we can track them
2. clients may query what events are available
3. dependency relations of an event will have a chance to become visible
4. usage of events in stored procedures or triggers will be better controlled and checked against the repository

We may (and do) accomplish this by preparng an events table, programming a client to listen to those events and call necessary procedures, etc. But why should we need to block a client for this? And why should we undertake the risks of a connection for such a central job? Actually, as long as hearing that something has happened doesn't mean much if you won't take an action, and the action to be taken is almost always there, on the server. So, why can't a server take an action on it? What about performance overheads?

Other features may be available by using a TMP$ table where
1. EVENT_ID
2. LISTENER_ID
fields are kept. As the server has to keep track of events somehow, even if for nothing more than sequentializing their execution, such a table would not hurt and we (or our server procedures) may query present listeners by looking at it.

An elegant addition might be giving clients an opportunity to invoke events. This would let us invoke a series of actions without going through calling parameterless stored procedures. We will also be able to build a fast and efficient central messaging mechanism by using it, too. One more use may be coding such events in our user programs as an RPC mechanism.

And as far as I understand, there's not much to it, is there?
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

None

Server Response from: ETNACODE01