: Jonathan Morton <[EMAIL PROTECTED]>
: The same goes for file transfer - and by that I mean across the Internet.
: Putting security concerns aside for a moment, I can run a freeware FTP
: server and/or client on my Mac with a reasonable amount of ease. However,
: these Macs are behind a double-firewall which I have little control over,
: and so accessing these services is extremely difficult. It's fiddly enough
: setting up a tunnel to run VNC through in the first place.
That's why I recommend a solution via an http server intermediary.
Because of firewall and portability issues. And then such a tool would
be useful for more than just VNC use.
: I hardly think that a simple file-transfer capability, such as the one
: I outlined the other day, would increase the executable code size by
: more than about 20K - and that's a pessimistic estimate, based on my
: experience with RISC processors (which usually have larger-than-normal
: code sizes).
Adding such a thing doesn't really require any modifications
to VNC servers, viewers, or the RFB protocol. Anybody who wanted a
VNC-specific solution could right now write two little items for both
ends of their connection, and package these with their own VNC
distribution, and use it as proof of concept. One to put files into
the cut buffer, and another to remove them from it. For unix on each
end, it could be done as a few dozen lines of tcl/tk or perl/tk.
But I suspect most folks wanting such a thing would want
a windows-to-windows version, not unix-to-unix, not so?
I'd still recommend a separate tool, though.
Plugging together the ends by talking to an httpd server
seems better solution to firewall and portability issues
than trying to plug the ends together via
the VNC connection.
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
