Jonathan Neve wrote:

>However, the problem is that since FireBird has not been made with this
>in mind, the only way to provide over the wire encryption and
>compression is to use a general-purpose tool (like Zebedee), that
>redirects at a low level all accesses to a certain local port to the
>correct destination, after having encrypted and/or compressed it. Now,
>this is all very well, but it's a lot of setup, because that means that
>I have to hard-configure Zebedee with one port for each remote host I
>want to be able to connect to. I can't simply set the host-name on the
>connection string, rather I have to connect to localhost at a predefined
>port, which Zebedee will then translate to the corresponding host...
>This is not very versatile, and it's a bit of a pain to configure...
>
>What would be wrong with providing this in the engine itself? Wouldn't
>it make things considerably simpler (for the end-user)?
>Or if this is not desirable, perhaps we could make some kind of hook
>that would allow external code to be performed every time anything has
>to go over the wire. This seems like an interesting idea in its own
>right (IMO), since it's a general-purpose solution, that would allow for
>loading extra modules dynamically, so that those who don't want a
>certain module don't have to install it... However, for the case at
>hand, I can't help but think that the former solution is preferable.
>
>Any thoughts?
>
>
>

Yes. The first thought is that it isn't the engine you're talking
about, it's the server. The engine responds to an API and moves bits to
and from a disk. The server listens to the network and makes calls on
the API into the Y-valve that does something appropriate, and on good
days, useful.

That pedantic obligation off my back, the original architecture of the
was a generic (network agnostic) server calling indirectly through a
"remote" block (gee, sounds like virtual method, huh?) to do stuff. The
actual line protocol flows through XDR which, in turn, calls putbytes
and getbytes indirectly through the remote block. Version 1 of
gds/Galaxy supported TCP, DECnet, Apollo ring, and JVCALP. So in
theory, all you need to do is make your own remote classes. Like most
cases, however, the phrase "theory" is translates to "it's not that
simple". And, alas, it isn't. The server code has been substantially
hacked by people not universally respectful of the original
architecture. I did an initial class encapsulation of the remote block
in Vulcan, but it's still somewhat of a mess. The other problem is that
the server finds its necessary and sufficient "remote" blocks with a
nasty warren of conditional compilation.

If you wanted to take on a very useful project, finishing the
classification of the remote stuff and fixing the server so find its
remote objects from the configuration file, you could an embellished TCP
remote that used SSL (or whatever), and squze them bits on the way here
and there, it would be a very good thing.