Definite no from me; too many complications, and it'd make what's a simple push install into a piggin' nightmare.
Nick Palmer IT Manager -----Original Message----- From: "Beerse, Corni" [mailto:c.beerse@;torex-hiscom.nl] Sent: 17 October 2002 15:28 To: '[EMAIL PROTECTED]' Subject: RE: Sound Support > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tony@;instaview.com] > I vote NO.. ( yes i know it wasn't a poll ) I vote NO too! > > Why you ask? Because it starts to get out of what VNC is > designed for, and > its a slippery slope.. before long we will end up with a 20mb > install file and > require 128mb of ram to run. My reason: vnc and the used rfb protocol works perfect to do kvm-like connections over tcp/ip networks. Other tools and protocols are available for other transfers: smb / samba for seamingless userspace network mounting nfs for seamingless systemspace network mounting ftp for file transfer on a per file base ssh for a secure network connection over insecure networks and I'm sure there exists a protocol and toolset for networked sound support. > > Its designed to be a small multi-platform utility for remote > control/viewing. Lets not loose sight of that, and just improve that > functionality.. ( if there is > much more that can be done to improve it.. ) > > Now.. a code fork into a project to develop something that > has everything > + the kitchen sink isn't a problem, as it would have its > place in life..... > > Just please dont do that to the base VNC and destroy it. I think if RealVNC is the successor of the origional vnc, they should keep it as lean and mean as it always was. Improvements and new platforms are appreciated but fancy features should be kept out of the official successor of the origional VNC. It's for spin-offs like tight-vnc and specially esvnc to add the stuff like filetransfer and sound. Then they must keep in mind that their servers must work with default viewers and their viewers must work with default servers (with loss of added features) Now I think of it, if the protocol has no hooks for those added functionallity, it would be nice to use the proper protocol (optionally over an alternate port) for the feature: to transver files, use ftp, samba or nfs protocol, then the new features can also be used if one of the 2 parties is standard but has tools for the other protocol available. For example: I have a standard viewer, talking to a vncserver that also includes an ftp server (say on port 5700+display ;-) then I can transfer files using my browser at ftp://vncservermachine:5700/remote/file... An example can be the webserver as already in Xvnc at port (5800+display). You can fetch all files from the .../vnc/classes directory at http://vncservermachine:5801/index.vnc CBee _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain privileged and confidential information. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. The unauthorised use, disclosure, copying or alteration of this message is forbidden. The Eric Wright Group will not be liable for direct, special, indirect or consequential damage as a result of any malicious program being passed on, or arising from alteration of the contents of this message by a third party. _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
