Jim Starkey wrote:

>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.
>
>

Ok.

>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.
>
>

I'm afraid my understanding of the internals of the engine is not
sufficient for me to fully grasp the intricacies of the above. But I do
gather that the code is a bit of a mess, which means that it would not
be easy to add over-the-wire compression/encryption...

But what do you think concerning the implementation? Should it be a
plugin, or simply a core feature of the engine?

Thanks for your reply,
Jonathan Neve.