loud kfilemetainfo thinking

[Thiago Macieira]

Jos van den Oever wrote:
> In my opinion the prominent role of the mimetype should be
>abandoned. We cannot continue working on the assumption that mimetype
>always accurately predicts which files contain which fields and that
>one mimetype maps to one KFilePlugin. A mimetype is just one of many
>metadata that can be associated with a file. It is well possible that
>a file has multiple mimetypes. An openoffice text document arguably
>also has the mimetypes application/x-zip and application/octet-stream.
>When getting data from this file you might be interested in the
>zipfile aspects of it.

I can accept that as long as there is one main MIME type. Whenever we need 
to deal with the file in a context-poor medium (for instance, if we're 
mailing it) we need to know the official MIME type for the file.

Other things that we now associate with the MIME type (icon, actions, 
especially the "open" action) can probably be better told by the semantic 
desktop. Or, at the very least, from the many MIME types possible.

Also note that KDE has had for a while the IsAlso relationship of MIME 
types. So, having multiple MIME types for a given file is not new. Nor is 
there being a main type.

What bothers me is the implication that your work has on the file 
association database. In theory, we want(ed) to switch to the fd.o MIME & 
file type database. So, please clarify this subject: how does your work 
and Sebastian's work affect the MIME & file association database?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070116/1c9bab9c/attachment.sig>