: An interesting "addon" that would not even require integration would
: be a very lightweight implementation of an application-mode
: peer-to-peer filesharing tool for systems that don't already have
: something like Netmeeting.
It would not be at all difficult to piggyback it on the
cut buffer transfer. I could prototype one for the unix-2-unix
case as a single shell pipeline. Not only could, I have
done so, workable up to files of at least a megabyte or two.
For a unix-centric implementation, something like:
zip - f1 f2 fN | encdec -be | xselection -cutbuffer 0 -
to send, and
xselection -cutbuffer 0 | encdec -bd | unzip -
to receive. Very simple, very easy. A GUI applet for windoze
is trivial enough to write, and a unix GUI could be wrapped around
the above.
The cut buffer has a size limit, but it would not be too hard to use it
multiple times. A general-purpose version was discussed on this list
some time back (see below). Use of mime encapsulation could make it
platform-neutral, and workable on most systems. But nobody
has bothered to do it, despite being dead easy.
To me, this indicates that the claim from earlier in the thread
file transfer capability _is_ a usage feature which goes hand in
glove with remote session control; that's why it is always
eventually integrated into such tools
is not accurate at all. It would be trivial to add, and it hasn't been.
People just don't need it. They can always use a non-bundled file
transfer tool, or just email themselves, and this is so easy to do that
there's little motive to adding the feature to VNC.
( Though mind you, PCanywhere's file transfer capability came in
handy once upon a time when Outlook was corrupting the file when
packing it in MIME for mat for emailing, but that's another story. )
If you disagree... just implement it. It's not hard.
As for me, I tend to simply use scp; I'm normally connected
via ssh anyways.
Wayne Throop [EMAIL PROTECTED]
Date: Thu, 15 Mar 2001 22:56:17 -0800 (PST)
From: [EMAIL PROTECTED] (Wayne Throop)
Subject: Re: file xfer
: "Morris, Steve" <[EMAIL PROTECTED]>
: I would have chosen .tgz format over pkzip but they are effectively
: equivalent and who cares if it is hidden from the user.
I thought pkzip (or zip, see below) would be more nearly universally
available. The .tgz format seems more unix-oriented to me.
: I suggest that a prototype start with the MIME encapsulation of a
: single file which can be eithor binary or TEXT. That lets us handle
: platform translation of CR/LF. Let the user zip and unzip it in the
: beginning. This defers such user interface questions as where in the
: tree to do the extract.
Right. The sender just clicks on (or types in the name of) a file, this
gets recorded in the MIME header, and the receiver can either use the
same name from the MIME header to save, or maybe have a way of
optionally storing to a different filename. That's enough to get
started: just MIME, no zipping to complicate things at this point. The
only thing beyond simple text bashing is the base64 format, which is
pretty straightforward; mmencode.c from the metamail package will handle
it, the source of which is easily findable on the web. Or try to find
a copy of encdec.c (which is packaged with nutnews). Add automagic
zipping for compression and/or multiple files after the basic xfer is
working.
: Does anyone know where to find mime64 and pkzip libraries?
Well... as you see above, I know where to find unix-pipe-oriented
code for this stuff, rather than libraries. But still, the metamail
package is a good place to start for the one, and the source for
the linux/unix zip/unzip code for the other. Findable on the web
via Your Favorite Search Engine.
: Raye Raskin <[EMAIL PROTECTED]>
: I'm just a little curious. Why do I keep seeing references to pkzip?
: Why not use just plain zip? Isn't it just a tad more portable? Isn't
: that what we'd want? And there are no license issues that I know of.
True. I called it "pkzip format" because the zip/unzip
public domain implementation for unix says
DESCRIPTION
unzip will list, test, or extract files from a ZIP
archive, commonly found on MS-DOS systems. The default
behavior (with no options) is to extract into the current
directory (and subdirectories below it) all files from the
specified ZIP archive. A companion program, zip(1L), cre-
ates ZIP archives; both programs are compatible with
archives created by PKWARE's PKZIP and PKUNZIP for MS-DOS,
but in many cases the program options or default behaviors
differ.
That is to say, zip/unzip is an implementation of pkzip format.
That is, I was thinking of the format as distinct from how to
pack/unpack it.
The above makes selection of where to unpack easy; you just add the
ability to navigate to any directory to the unpacking tool; then pass
the buck to unzip. Makes it a really easy step up from
single-file-transfer mode. Since we're wrapping the whole thing in
MIME, there's plenty of metadata: just have the unpacker look for an
appropriate Content-Type and/or extension on the filename in the
Content-Disposition to decide whether to just store it or pkunzip it.
[EMAIL PROTECTED] (Wayne Throop)
---------------------------------------------------------------------
To unsubscribe, mail [EMAIL PROTECTED] with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
