> I have been looking at / considering what improvements - if any
> we should make to the remote protocol.. From an IBReplicator
> perspective I know that the conversations between client/server and
> back are pretty chatty, by that I mean there is a lot of too and
> from conversation. Over a WAN this slows down replication to what
> some users would consider an unreasonable degree...
>
> As such I am looking for any specific information/measurements that
> any of you may have done that define the "problems" before I start
> having to do this myself. i.e how talkative is Firebird for example
> in comparison to other databases?

My impression is that without changing the API we will not win too
much. But here are my list of possible improvements that can be done
without changing the API (possibly only introducing new methods):

- isc_attach_database: one packet is sent in op_connect, then we wait
for response, then another packet is sent with op_attach; these two
should be combined together, one roundtrip less;

- combine together isc_dsql_prepare and isc_dsql_sql_info. At least in
JDBC driver these two operations go together, so there is no point to
have excessive roundtrip (proposal: isc_dsql_prepare2 that also
returns the XSQLDA)

- combine together isc_dsql_execute2 and isc_dsql_sql_info to return
the number of inserted/updated/deleted records even if application did
not ask for them;

- we should check whether isc_dsql_execute2 should also already start
returning records (something similar to combining it with
isc_dsql_fetch), should reduce roundtrips for short queries;

- fetch small BLOBs together with the response (a-la VARCHARs) and
support raw BLOB data in XSQLVAR. This would reduce the number of
roundtrips for BLOBs significantly.

That's basically all improvements that we can make on the protocol
level with the current API. Some of the improvements components can
make internally, e.g. using isc_dsql_exec_immed for queries without
parameters or to cache metadata locally, etc.

Roman