Trouble with gzipped files

[Luis Pedro Coelho]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Friday 20 June 2003 23:58, Thiago Macieira a écrit :
> Luis Pedro Coelho wrote:
> >In that bug's small discussion, Thiago suggested assigning
> >application/postscript; compression=gzip to *.ps.gz
> >
> >This seems very logical, but I don't really know whether this corresponds
> > to any convention used elsewhere. I tried look through the existing
> > mimetype [Thiago, can you answer this? I am CCing you bc of this
> > question].
>
> No, I am not aware of this approach being used anywhere. But from my
> understanding of the MIME RFCs and our current situation, I think this
> would be the most interesting approach.

Ok, I see.

> >I sometimes see posts about a mimetype hierarchy system, where I imagine
> > one would have (in pseudo-OOP syntax)
> >
> >namespace application {
> >mimetype "x-gzip"
> >mimetype "postscript"
> >mimetype "postscript;compression=gzip" extends x-gzip, postscript
> >}
>
> Now that would be interesting and would open up for new possibilities, even
> though by far the most beneficial would be compressions. Even if we don't

One could also derive html from xml so that a xml editor could be found to 
edit a html file. On the other hand, khtml would only be found for html. This 
sort of things.

> HTTP uses a slightly different approach, which is:
> Content-Type: application/postscript
> Content-Encoding: gzip
>
> This is another solution.

I don't really see how to directly map this to KDE's API without changing too 
much... So, I think that attributes solution should be the best.

> >Thinking smaller, just allowing "application/postscript;compression=gzip"
> > to find kghostview which offers "application/postscript, Application" and
> > "application/postscript,Browser/View" and then inside the app, let it
> > find the correct filter would be great. No apps would need much to handle
> > compression, if that was the case.
>
> That would be generally the idea. It would allow the correct application to
> be found as well as the correct filter for inside that app.
>
> Alexander Neundorf wrote:
> > If it found something known in the uncompressed data (e.g. postscript),
> > it returned a mimetype like text/html-gzip. Additionally I added mimetype
> > files for gzipped postscript, html, text and troff files.
> > But after some discussion on the list this wasn't considered a good
> > approach.
>
> I think we should get back to your idea. While creating new MIME types for
> each possibility doesn't strike me as a good approach, maybe using the
> attributes would solve the situation.

Here is a link to the older discussion I believe Alex is talking about:

http://lists.kde.org/?t=101795585700007&r=1&w=2

My only opposing thoughts have to do with backward compatibility. I don't 
think we can change KDE so that a file which used to return a certain 
mimetype changes to return another (unless it was a bugfix, of course). So, 
maybe certain apps are counting on the fact that we have "application/x-gzip" 
for any gzipped file and they will fail when they get "something/other; 
compression=gzip". Maybe this should be considered an API change...

The solution could be a slightly smarter mimetype class and having two ways to 
get the mimetype: a legacy interface which gets an old QString and a newer 
one. One could have:

MimeType type = //....;

if ( type.attribute("compression") != QString::null) { 
	//...
}

if ( type.isType("application/pdf")) {
	// matches even if full type is "application/pdf; compression=gzip"
}

QIODevice dev = filterForFile(file, type) ; 
// unencrytion, uncompression, whatever gets implemented.

I looked through the thread linked above and didn't find any code. Alex, did 
you actually post the code or did you only have it yourself?

Even if you don't have the time, I could adapt it and write a patch to 
implement the above. Or I could probably write from scratch if the code is 
lost.

Regards,
- -- 
Luis Pedro Coelho

The carrot tax, see:
http://luispedro.journalspace.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+9InRGpBAvyRwXdgRAh5uAKCSBl9U86CC2wCdzST/RqSoxXe4vwCfdT1Z
JCZP2eJK+eKGOECG5Vi7wM4=
=rnBc
-----END PGP SIGNATURE-----