> I agree that dataset synchronization could potentially be a poor scaling
> solution if abused by the developer.

I do not want to generalize the developer community but,
our experience here has been that if its available for
abuse it likely will be abused. Designed on the desktop
where performance is great, deployed to the field only
to find that it doesn't work well or at all. Good doc
can help but, often is overlooked by the masses. The
call will arrive on our phone claiming poor performance.
Suggesting a re-write or highlighting poor design when
the app is believed to be production ready is not fun.

The classic example is a BDE app that browses data with
a TTable. Rapid opening and closing kills the server
and floods the network with its fetchall behavior.

I am assuming that messages like events would not require
a transaction to be registered in their interest.

> But, if the synchronization was done right it would be
> quite a bit more efficient than constantly refreshing
> queries over and over.

Getting it right is the tough part. Thus, my enjoyment
in reading this thread. There is a lot of creative stuff
being offered up but, I'm yet to be convinced that a
query to refresh the dataset is _not_ the best method.

> Especially for low bandwidth connections.

Perhaps designing client app with behavior more appropriate
for the available bandwidth should be a design focus.

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

Sounds real messy. And what if the data changes rapidly?
I think the client should control data refresh behavior
rather than the server.

> since in client server apps it is typical to have small
> specific datasets

What equals 'small' and for what level of bandwidth/hardware.

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

Haven't put a lot of thought into it but, now that I must:

Messaging type stuff:

- System Crash Notification (would require the ability
to attach to the Guardian or something like it).
- System / Database to be Shutdown Notification.
- System Panic Information.
- Data related params to be used in a client query.
Perhaps and entire query string.
- Processing related (eg. "gbak completed successfully")
- Perhaps a remote logging / monitoring facility.
- A messaging specific client that does 'stuff' perhaps
database or not database related.
- Failover info (eg. server x failed, failto:server:/.../x.gdb).

Markus