loud kfilemetainfo thinking

[Jakob Petsovits]

On Tuesday, 16. January 2007 00:26, Jos van den Oever wrote:
> Hi all,
>
> You've probably looked at KFileMetaInfo and KFileMimeTypeInfo. In
> moving these classes forward to the semantic desktop, I think there is
> quite a bit of low-hanging fruit to be gotton by keeping large parts
> of the API but changing the implementation of metadata reading and
> writing.
>
> I will give you a small idea of what i think should happen to these
> classes. In my opinion the prominent role of the mimetype should be
> abandoned.

Note: It seems that Gnome developers also want to revamp the mimetype system, 
even if a bit differently than you described it:
http://blogs.gnome.org/view/cneumair/2007/01/14/0
http://joeshaw.org/2007/01/14/452
https://wiki.ubuntu.com/Usability/SpecEnhancedPreferredApps

Maybe there's a chance to cooperate on this issue and keep improving the 
fd.o mimetype database instead of undertaking a KDE-only solution.

> 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.

The mimetype already has this information in form of the X-KDE-IsAlso property 
in the mimetype's desktop file. (For example, see any of the source file 
mimetypes, say, kdelibs/mimetypes/text/x-java.desktop.)
One could make a point by saying that this information is not properly used, 
but I wouldn't blame it on the mimetypes themselves.

-- Jakob