Subject Re: [IB-Architect] Messaging API
Author Jason Wharton
> I am enjoying these Events and Messaging discussions.

Me too. I've got some refinements to my ideas brewing but a little
restrained still. Gotta run to the state capitol in just a few minutes...

> I hope that we do not go the route of a mechanism
> to be used for:
> a) Automatic Replication


> b) Automatic server data push to clients for data set
> sychronization.

Partially agreed.

> I've seen both attempted with Events and they were
> nasty network intensive solutions that didn't scale.

I agree that dataset synchronization could potentially be a poor scaling
solution if abused by the developer. But, if the synchronization was done
right it would be quite a bit more efficient than constantly refreshing
queries over and over. Especially for low bandwidth connections. This would
be the case where such a mechanism would be employed. I believe there are
needs for it.

In IBO the dataset synchronization would only require that the key columns,
key values and action (insert, update or delete) be pushed to the client. In
most cases it would be three pieces of inf. only since I use surrogate keys
quite a bit. Then, the client will take care of fetching the rest of the
pertinent data for the synchronization if it needs to take any action. In
most cases the message would probably be ignored...

This certainly isn't a really big deal since in client server apps it is
typical to have small specific datasets that are fetched, used briefly and
disposed of. 99% of my apps are just like this.

It may also be worth considering making these messages kinda hang out a
little and see if they can piggy-back themselves onto other info packets
heading back to the client. If a little latency isn't a big deal then this
might be a way to conserve bandwidth some... I imaging that most packets of
inf. being sent to the client have a little extra room in them at times.
Feel free to flame here. It's just a thought that popped into my head.

What I would like to know from Markus is what you invision the messages to
be used for if it isn't something along the lines of what is above.

Jason Wharton
InterBase Developer Initiative

InterBase will be the database of the new millennium.