: "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, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
