Ok, from now on, only those who would have something to do with the
development of such a feature in VNC need reply. I can't stop you, I'm just
suggesting that there is no need for you to. We've all heard that a bunch
of people want it and a few people don't (for reasons that don't hold
water). Now, the thread has resorted to belittling people because of the
operating system that they choose to run and so forth. I think that we are
way off topic here, and bickering is not going to get anything done.
If someone wants to tackle it from a VB end for us lowly Windows users,
let me know and I'll go in on it with you. If someone wants to make an
executable in C++ or something to make it easier to distribute, then go
ahead, but I regret that I can't help much there. I'm not sure if I can
free up enough time to do it all myself, so if there are any VB programmers
out there itching for a project, email me at [EMAIL PROTECTED] Let's
stop bashing on each other and start getting productive. Cool?
-Steve Bostedor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Wayne Throop
Sent: Wednesday, March 14, 2001 4:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: FTP Server
: 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
---------------------------------------------------------------------
---------------------------------------------------------------------
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
---------------------------------------------------------------------
