KMimeMagic::finishResult() useless ?

[aleXXX]

On Thursday 04 July 2002 13:17, David Faure wrote:
...
> > Or is it there for future extensions, where the mimetype-string may
> > contain an encoding entry ?
>
> Well, it's there because it comes from the apache mimemagic code, which
> does support encoding in the mimetype string. It's commented out in
> KMimeMagic since we don't support that at the moment, but if anyone wants
> to introduce that somehow, the code for it is already there.
> Not that it's make much sense IMHO though (we all know how badly
> heuristics to find out the encoding of a file work).
>
> > But why is it then commented out in KMimeMagic::findBufferType() and
> > findFileType() and replaced with a simple stripWhiteSpace() ?
>
> See above.
>
> > Would a mimetype string with encoding look like "text/html gzip" ?
>
> Hmm, that's not an encoding, that's a compression method.
> Encoding is usually stuff like utf8, iso-8859-15, etc.

Well, I don't know.

http://lists.kde.org/?t=101795585700007&r=1&w=2
http://lists.kde.org/?l=kde-core-devel&m=101813637216720&w=2

At least I have code here which recognizes compressed html, ps, troff, 
whatever files as such. Now what to do with that information ?
E.g. for a gzipped html file ?
"text/html; compression=gzip" : hmm, see above
"text/html-gzip" : doesn't scale
"text/html" : well, the apps/parts have to handle the compression then

I'd vote for three, basically we'll have compressed ps, troff, text, maybe 
html/xml files, not much more. ps and troff are already working.
Do we actually support gzipped html files ? There exists a module for apache 
to deliver the html files compressed.

Bye
Alex