I once suggested that it might be good to go one step further and have the client and server programs changed to be soly able to load other libraries and then handle the communication between them.
Thus you'd run the client, tell it what network protocal you want to use and which server you want to connect to. First it would ask the server for it's thoughts on compression (Required, Prefered, disliked or refused) and a list of the compression libraries, thier versions and the lowest version that they are backwards compatible with. It the uses the users preference for compression and the matching libraries to compress the data stream. Then the same thing is done with encryption. Then login. The a list of actual applications would be retrieved. This would include VNC, it could include a file transfer program (instead of it being part of the remote control VCN code), a printer sharer etc. You could run any available application. You could change the contression and encryption settings for any running app. All the apps would just pass the data they want sent to the hub program and it would be responsabel for the encryption, compression and sending back and forth. With this setup the applications don't need to know how to communicate, so new protocals can be added, new compressions and encryptions etc and nothing except the hub code cares. The applications themselves whould use a plugin system as well, so VNC would have plugin screen change catchers and encoders. The whole system would allow you to have a small footpriint since if you don't want to carry the compression, encryption, alternate network protocols, other addings etc you don't need to. It also makes it much easier for people doing add ons as they don't have to wait for other upgrades. Foe example, if new code gets added to the base VNC code and you are using eSVNC you have to wait foe the changes to be incoperated in TightVNC, and then for them to get into eSVNC. With a plugin system you'd just grab the updated VNC plugin and continue using the eSVNC plugins you already have. Another interesting option would be to add an updater to the startup sequence so you can, for example, instal the server on 500 different machines in your company, tell thgem that they are to accept updates from teh four machines designated as the support machines. Then, when ever you connect to them from those support machines the latest versions of the plugins will get sent to the server and placed in the plugin directory for immidiate use. Imagine never having to upgade a clients machine ever again :-) You could even have Linux, Windows and Mac plugin directories on your machine and have the updates sent out as required to different end operating systems. If the four support machines are all running VNC from a file server then there is only one copy of VNC that you have to manually update, and that it the one on the server. For even easier updates I'm sure that someone will come up with a plugin application that will update your copy of VNC and all it's plugins of different OSes from a master archive on the internet. Obviously this would wind up having an incompatible communications and requre quite a bit of program to get started, but it would lead to easier development and upgrading in the future. I don't see it happening, as the initial work will put everyone off, but it always seemed like a great idea to me. Ian Simcock. _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
