|Subject||Re: [IB-Architect] Messaging API|
> I agree that dataset synchronization could potentially be a poor scalingI do not want to generalize the developer community but,
> solution if abused by the developer.
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 beGetting it right is the tough part. Thus, my enjoyment
> quite a bit more efficient than constantly refreshing
> queries over and over.
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 requireSounds real messy. And what if the data changes rapidly?
> that the key columns, key values and action (insert,
> update or delete) be pushed to the client.
I think the client should control data refresh behavior
rather than the server.
> since in client server apps it is typical to have smallWhat equals 'small' and for what level of bandwidth/hardware.
> specific datasets
> What I would like to know from Markus is what you invisionHaven't put a lot of thought into it but, now that I must:
> the messages to be used for if it isn't something along
> the lines of what is above.
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).