[interfacekit] Re: __mime_table
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Mon, 12 Aug 2002 16:23:16 +0200 (MET DST)
On Sun, 11 Aug 2002, Tyler Dauwalder wrote:
> When writing the BMimeType::GetSupportingApps() tests, I decided to
> manually build my own supporting apps table and compare it to the
> information returned by GetSupportingApps(). The strange thing was,
> for certain types, GetSupportingApps() returned *more* app signatures
> than I had collected by compiling the META:FILE_TYPES attributes of
> all the "application/" types. Furthermore, I was finding app
> signatures that didn't even exist in my database.
>
> I eventually discovered that this extra information was being taken
> from the file "__mime_table" in the root directory of the MIME
> database (which is just a flattened BMessage). The interesting thing
> is, if you change the __mime_table file (i.e. by unflattening it,
> adding to it, then re-flattening it), it 1) has no effect on
> GetSupportingApps() (not too surprising, the registrar probably
> caches it) but 2) is eventually (i.e. within a few minutes) restored
> to its original condition by some agent (again, assumingly the
> registrar).
I played a bit with the meta MIME information when we wrote the BMimeType
tests, but, damn, I can't recall the details. What I do remember is, that
after all it sounded quite plausible.
> I assume, then, that somewhere there is an API (possibly just a
> message protocol to the roster/registrar) to make concrete changes to
> the __mime_table, as my __mime_table is larger than the __mime_table
> of a clean install, and contains entries from applications I once
> installed but have since removed (such as BeatWare Mail-It). Does
> anybody know about such an API (presumably from the olden days) off
> hand?
Mmh, the API to add meta MIME entries is create_app_meta_mime(). Removal
is, I believe, a side effect of BMimeType::Delete(). Furthermore some
BAppFileInfo methods do affect the meta MIME info.
> I suppose we ought to try to support this API if we want to be truly
> backwards compatible, but I don't currently have any great
> suggestions as to how we should go about this. I'm not going to put
> too much effort into it right now, as there are other things that
> need doing, but I thought I'd mention it here so we don't forget to
> possibly look into it at a later date. :-)
Well, I hope what I mentioned is all the API there is, but I can have a
look into older versions of the BeBook.
> One other MIME related thing I should mention is that, while speaking
> with AnEvilYak a few weeks ago, he noted that the automatic MIME
> sniffer on his system never runs when he has something like SETI
> running in the background all the time. He mentioned that it might be
> nice if we could implement a way around this, as he always has to
> manually identify files otherwise.
Very good point. Perhaps it is sufficient to not just to look, if there
are spare CPU cycles at all, but, in case there are no spare cycle, to
analyze what priority the processes have that consume most of the cycles.
Supposing that SETI and similar background number crunching processes have
the lowest imaginable priority, this seems to be a reasonable strategy.
CU, Ingo
Other related posts:
