mime-type icons, a proposal

[Alexander Larsson]

On Fri, 2004-10-01 at 17:55 +0200, Alexander Larsson wrote:
> On Fri, 2004-10-01 at 17:29 +0200, Waldo Bastian wrote:
> > On Friday 01 October 2004 16:28, Alexander Larsson wrote:
> > > > Your file-type detection returns a type and then you ask "is this type a
> > > > wordprocessor document", and then it will return yes or no, depending on
> > > > whether the type inherits from the generic wordprocessor document type.
> > >
> > > Thats not right. Right now the "inheritance" in the mime database is
> > > specifies actual physical compatibility. E.g. application/python-src
> > > inherits from text/plain. We don't want to overload this with another
> > > type of inheritance ("is a file used by the same sort of application").
> > 
> > No, the inheritance specifies "is also". The mimetype itself specifies actual 
> > physical compatibility. Files of type "text/plain" have certain 
> > characteristics ("application/x-gzip" would make a better example since it 
> > would actually imply a certain well-defined file-format) So when 
> > "application/python-src" inherits from "text/plain", we say it "is also" of 
> > type text/plain: it has also all the charactestics typical for the 
> > "text/plain" format (If it had inherited from "application/x-gzip" it would 
> > mean that files of the "application/python-src" type had the gzip file format 
> > by definition)
> > 
> > The "wordprocessor document" type means "document generated with a 
> > wordprocessor", this doesn't translate to a particular on-disk file format 
> > (which is why the file type determination function will never return it as 
> > type) but the inheritance relationship is the same, if another MIME-type 
> > inherits it it means that having a file of this other MIME-type also implies 
> > that the file has all the characteristics of "wordprocessor document".
> 
> I still don't like adding nonstandard MIME types that are not even
> "real" mime types to the database just because this allows us to use an
> implementation detail to allow search-by-category. I mean, the same
> results could be gotten from defining a key "is-of-category" in the mime
> database, and filling it in like you would fill out the inheritance with
> fake mimetypes. The UI for using this would be exactly the same as the
> one that used fake mimetypes. (I.e. It'd contain a dropdown list of
> known document types to look for.)
> 
> It also avoids some multiple inheritance.

Also, it means that if you want to use the category to pick the fallback
icon that is easily determinated, which it isn't if you use the normal
inheritance for this. If your document type inherits from both gzip and
"spreadsheet", how do you know which one to use for icon?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a witless Jewish vampire hunter looking for 'the Big One.' She's a 
time-travelling punk museum curator who believes she is the reincarnation of 
an ancient Egyptian queen. They fight crime!