Jim Starkey wrote:

>The protocol reflects the API. Do you have any suggestions for reducing
>the number of round trips?
>
>

The problem with internet (that it's a little bit different of the
problem with slow connections) is latency.
Small packages that need ACK's all the time is our problem.

Our client "talks" to the server a lot for simple operations. For a
Select that returns a small tuple, compression will not make a
difference (small packages, time waiting for ack's it's the most
expensive operation). For selects that returns a lot of data,
compression makes a diference.

IMO, we don't need to implement compression in the engine. There is a
lot of software/hardware solutions that could provide this feature to
the users
I think about encryption in exactly the same way.

For our problem, a simple example is a Select statement to collect data
from the server. If our client could request 'Open Transaction' +
'Select BlaBla From XPTO into bla,bla,bla I_Don't_Care_About_The_Plan +
etc + 'Fetch All' + 'Commit' + 'Close Transaction' in one simple go
(batch/block operation) and return a 'All or Error (with auto rollback)'
- that will improve a lot internet performance. And that will please a
lot of users, even in a non-internet environment.

I think it's this kind of batch/block operations that Stan was talking
about.

I don't have suggestion for reducing the number of round trips. I don't
really know if it's possible or not. You tell me. :-))

Artur Anjos