On 9/10/98 at 8:29 PM -0400, Al Costanzo wrote:
+I disagree, LZJU90 in most cases compresses objects further and is never
harmful.
Give us a few examples. (Most of us are too lazy to do this work
ourselves.) Take a standard JPEG. Encode it using base64. Then encode it
using LZJU90. Tell us what the size difference is. Give a few examples like
this (MPEG, zipped files, some sound compressions). It should be easy
enough for you to get some files and post some numbers since you've already
got the code running somewhere.
If it doesn't cause increases in file sizes and gets some savings, then it
starts to be more likeable.
- First of all, I fail to follow the argument about why this needs to be a
top-level type. Huh?
Well, the FS draft which you see is actually the third attempt to define
FS as a media type object. Feel free to help out here...
The first, which Ned saw, attempted to define it as a top level type called
FS with subtypes being file systems.
The problem with that iteration of the draft (which was pointed out to me)
would be that implementors would most likely use the type definition to help
decode an object for a specific platform. [You'll have to trust me for a
little while on this statement.]
This would cause a problem since FS should be able to deal with this
internally. The concept is nothing like gzip which uses a value to tell you
from what file system an object came from. FS written for a specific
platform will handle this properly.
Fine. All that put together argues that FS is actually a container format
itself with multiple objects inside of it, similar to tar or StuffIt. If
that's the case, then there is no question it should be a subtype of
application: It should be application/fs. There is still no explanation
here of why it should be a top-level type. Would there be any reason for it
*not* to be a subtype of application?
I agree that it would be nice to have a way to transport
filesystems, but I think we would be better off working on something like
multipart/fs along with some new Content-Disposition parameters or
something.
Right. This would lend itself well to current MIME implementations.
I am open to suggestions -but- I would like backwards compatibility and fs
objects recognized as some form of media type. I believe what you just
stated will not allow this to happen so I must oppose it.
You're correct; I don't think there is any way to get backward
compatibility with current FS implementations without either (a) making it
an application subtype and forgetting about MIME structure information or
(b) changing FS to make it MIME like. That is, either you end up with
something that isn't internally MIME, or something that isn't internally
FS. I don't see any way out of that.
Like Steve, I like the idea of a MIME multipart/fs, but I don't think Al's
proposal gets us near that. FS is just another archive format like tar or
StuffIt.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102