: "Morris, Steve" <[EMAIL PROTECTED]>
: Why is discussion so adversarial. One class of users has a problem
: and keeps posting requests. Another class of users desn't have that
: problem and basically declares the first group to be stupid because
: they can't figure it out.
Well I certainly apologize if my comments were taken as an
accusation of stupidity, or an assertion that the problem doesn't exist.
The problem DOES exist, and discussing a solution to it is NOT stupid.
But I stated
1. what I'm doing now to transfer files, as a practical
short-term method of getting on with work
2. suggested two ways that a practical file transfer tool
could be made out of already-available building blocks
which didn't have the problems of using FTP, based on (1)
: I think we have a UNIX guru v.s Windoz end user split here.
That may be. For example, a difference in expectations as
to the user interface one can expect from a file transfer tool,
and what mouse gestures and GUI dialogues it should have.
But I still think an adequate solution can be had, which doesn't have
problems with firewalls (or at least, not many), and which has an
adequate user interface even to Windows-users expectations, and without
the necessity of loading down VNC with extra features in the RFB protocol.
Thus I would still not like to see the RFB protocol have this
particular addition made to it; I still think it would be a mistake.
: What would be helpful as a start is for someone to collect the
: currently existing solutions into a single document and then somehow
: make that document available to VNC users, probably as a pointer in
: the FAQ.
Part of the difficulty in doing so is that what makes for
an acceptable solution varies a lot with environment and user
expectations/preferences. Still; listing lots of solutions and
pointing out their pros and cons seems like a good idea to me.
So, to start off
method: transfer file content via cut and paste
pros: will work almost universally, and even heterogeneously
cons: multiple and binary files are a pain (but doable)
and there's no point-and-click selection of files to transfer,
only "copy" or "cut" of a single content, and extremely large
files are likely to cause problems
method: transfer using an http server site visible to both
local and remote host as intermediary
pros: will work almost universally, and even heterogeneously,
with any system that has a web browser on the receiving end,
and binary files of most any size can be dealt with
cons: the sending end hasn't got a standard, universally available
protocol (it depends on the http server's conventions),
transfer of multiple files at once would require construction
of a self-extracting binary and thus not be generic
Note: putting user-friendly wrappers around the above two methods to
deal with multi-file and binary transfers are very possible, (especially
portable would be a java applet to manage the uploads and downloads via
an intermediary, passing a session ID via the cut buffer between local
and remote ends; might not even need to store anything on the server),
but details of implementation and security management would be
situation-specific. Creating such user-friendly wrappers for common
circumstances seems like a good idea, though.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
