Behold the genius. ;) I only hope that this doesn't fall upon deaf ears.
Maybe if the people that really need this functionality ask with a unanimous
and overbearing PLEASE!
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Morton
Sent: Tuesday, March 13, 2001 8:30 AM
To: [EMAIL PROTECTED]
Subject: RE: FTP Server
>A built-in FTP server would be great, when using internet connection, not
>lan.
I'm thinking that maybe FTP per se isn't a good idea, mainly because it's a
surprisingly big and complex protocol to implement. Ever noticed that
*good* FTP clients and servers are hard to come by, especially for
"desktop" systems such as Windows and Mac?
How about a (simpler?) protocol which embeds "packets" of a file
intermingled with regular RFB messages in a single connection, which would
also make life *so* much easier for ppl who have to get through firewalls.
Some means of encoding metadata associated with a file (eg. Macintosh
filetype, UNIX file permissions) would also be highly desirable, so that
files transferred between machines of the same platform remain as intact as
possible.
Clearly the Macintosh has special problems in this area, and always has
done, but this can be worked around using the following simple method:
- The file header always contains UNIX-style file permissions, eg.
read/write/execute access for owner, group and world. The "names" of the
owner and group may also be encoded with this information. Platforms which
do not support file permissions should set sensible defaults on
transmission and ignore on reception.
- If a special platform flag or value is set in the header, the file is
encoded using an industry-standard method such as MacBinary or BinHex. The
recipient can either decode the file (if it understands the format in
question), send it to a helper application for further processing (eg.
StuffIt Expander) or, if it does not understand the format, simply save the
binary stream as-is. This binary stream could then be manually run through
a separate, industry-standard decoder with no data loss. Information
within the encoding should over-ride permissions information in the header
where applicable.
- If no special platform flag/value is set, the file should always be saved
as-is without further processing, subject to the permissions flags provided
in the header. The sender should provide options to set or clear this flag
at run-time on systems which support this feature.
- Filenames, usernames and group names may contain any valid ASCII
characters, terminated by a NULL. If the recipient system cannot support
the filename encoded in this manner, it should either discard the
information (for user/group names) or transform the information to a
compatible format in a consistent and non-destructive manner. Eg,
replacing spaces by underscores, transforming case, truncating. Where
possible, truncation should preserve the file-extension (eg. .GIF) and
avoid over-writing files that already exist by generating unique filenames.
- The recipient may save the files in a standard location, which should be
user-configurable and should *not* default to any location where the files
may be automatically interpreted by the system (eg. UNIX home directory).
Alternatively - and this is preferred - the recipient should prompt the
user for a location to store the files at run-time. Both the server and
viewer may do this, since dialogs shown on the server are transmitted to
the viewer anyway.
- Where many files over a long period of time are transmitted, a batch
feature may be desirable so that all files in the batch are saved to the
same location. Such a batch feature may include support for transferring
entire directory structures, in which case a standard directory delimiter
character should be decided upon and a method of escaping this character
(perhaps by doubling) provided in case this character legitimately appears
in a filename.
- The packets making up the file transfer should not be so big as to
unacceptably reduce RFB performance during the transfer. Ideally, this
should depend on the bandwidth of the channel in question - small (less
than 1K) packets for modems, with bigger packets for better performance for
LANs. There should be a ceiling on packet size, perhaps 64K, to prevent
naove users from hopelessly impairing their RFB performance unwittingly.
For reliable and efficient transfer, each packet should be marked with an
offset and length, along with an ID uniquely associating the file with it's
header - this should enable resuming of broken transfers, and allow
multiple transfers per TCP connection.
Note, however, that implementation of all the above features - particularly
special-platform and batch support - should not be a requirement. Simple
and reliable file-transfer functions should not be too hard to implement in
an extensible manner, provided this is planned correctly. At the very
least, a "feature not supported" message should be available.
Just my 2p...
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
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
---------------------------------------------------------------------
