Daniel Rail wrote:

>Personally, I would like to see compression and encryption plugins
>capability. And, a well thought out wire protocol could also support
>multiple compression and encryption plugins for the same server and
>that the client can use whichever plugins that the developer wants to
>use. But, the downside would be that for the plugins to work, you'll
>have more files to distribute on the client systems. Also, the
>compression plugin might not be required if the wire protocol is well
>designed and has a fast performance over a dial-up connection(which is
>not the case today).
>
>
>

I don't think it is necessary or even wise to use different remote
modules to support different protocols. The protocol from the dawn of
times starts with a protocol negotiation, which allows us to slip in a
new wire protocol that new clients can use while still supporting old
clients. Whether it makes more sense for line encryption to be
implemented as a separate remote module or as a protocol option is a
pragmatic decision. An SSL implementation, for instance, requires that
the secure connection be created before communication starts, rather
precluding protocol negotiation. A pure Firebird solution, on the other
hand, could be implemented as an extension to the internal protocol set.

Compression could easily be handled within the context of the existing
remote layering and protocol negotiation. All that is needed is for
somebody to put a zlib layer in the the TCP remote module. There are no
significant issues at all.