I like this idea - it even has some potential for easy scripting on either end since their are some scriptable base64 tools on Windows.
----- Original Message ----- From: "Wayne Throop" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, 2002-05-21 01:26 Subject: Re: vnc-list-digest V1 #1570 > : 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 > --------------------------------------------------------------------- --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
