Subject | RE: [IB-Architect] Re: Events Improvement |
---|---|
Author | Dmitry Yemanov |
Post date | 2001-05-07T07:14:17Z |
Doug,
a single delivery of all satisfying requests to decrease the number of calls
through the network. I can imagine that somebody updates a lot of records in
a table, and your AST routine is called hundreds or thousands times.
And I think, if you design your client application to use the masks, then
you could a bit change your application logic as well. Just ignore the
results of isc_event_counts (or don't call it it all) and use another API
function, that will return which events occurred and how many times. Then
you can iterate through the results and do the same as you wanted to do with
a single notification.
But anyway it is a subject of discussion. I don't say my design and
implementation are the best ones. This is the reason I posted my thoughts,
so any useful critics and good suggestions are welcome.
Cheers,
Dmitry
> If my client application registers interest in event 'A*' II was thinking about this and it can be done. But I have chosen variant with
> would rather be
> notified for each A1, A2, A3 event separately and not be
> notified that
> event 'A*' occurred three times.
>
> This would be a change in semantics for 'A*' but a very useful one.
a single delivery of all satisfying requests to decrease the number of calls
through the network. I can imagine that somebody updates a lot of records in
a table, and your AST routine is called hundreds or thousands times.
And I think, if you design your client application to use the masks, then
you could a bit change your application logic as well. Just ignore the
results of isc_event_counts (or don't call it it all) and use another API
function, that will return which events occurred and how many times. Then
you can iterate through the results and do the same as you wanted to do with
a single notification.
But anyway it is a subject of discussion. I don't say my design and
implementation are the best ones. This is the reason I posted my thoughts,
so any useful critics and good suggestions are welcome.
Cheers,
Dmitry