>I would also like to argue that these are two different issues because when
>InterBase is populating packets to send over the wire it knows nothing

about

>what hardware or software compression is performed and as such it cuts off
>the packet's fill point at a fixed packet size boundry. It isn't able to
>overstuff a packet to 80K knowing that compression algorithm X is being

used

>in order to get it down to the 64K size.
>

Lately, I've been thinking of economics in relation to the Interbase and the
community. The key phrase is "diminishing returns".

I think, as a community, it would be good to note that some things, like the
engine, have already reached the state of diminishing returns (meaning you
no longer get that much benefit from the amount of resources and work you do
because it is pretty much done, and doing quite nicely already without
additional work).

But there are some areas like network/connectivity where a little work done
generates much much more benefit because there is a lack in that area.

I think, this has been pretty much the point of Jason W. I noticed that his
recent posts have been related to making IB more efficient and more robust
in the network/connectivity area. And this is the area where a little work
done would provide great benefits. Like for instance, a more robust network
error detection/correction would be nice because the presence of a slower or
errant network card can hurt Interbase / while the network and other
database engines hardly feel it. Or for instance, the misconfiguration of
the Netbeui vs TCP/IP, etc...

I noticed that Oracle, DB2 and other databases have their own Network layer.

My point is that, there are some things in Interbase that no longer give
back that much benefit/improvement in performance and features no matter how
much work you do; but there are also areas - like this one that Jason W is
pointing out - that a little work would give much benefit.

It would be nice to give priority weights to the To-Do's based on its
"diminishing returns" rate.

Joseph Alba
jalba@...