FreeLists / openbeos / [openbeos] Re: kernel mime_table module

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-01-04 at 18:38:57 [+0100], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2005-01-04 at 15:25:32 [+0100], Axel Dörfler wrote:
> > > "François Revol" <revol@xxxxxxx> wrote:
> > > > src/add-ons/kernel/generic/mime_table
> > > > comments ?
> > > Sounds like a good idea for now.
> > ... aside from that it doesn't really belong into the kernel at all.
> > We
> > already have a userland service that provides an even more generic
> > mapping.
> > IIRC the only reason for having such a mapping in the existing FSs is
> > that
> > the Tracker or the respective API (BRoster,...) don't deal with files
> > from
> > typeless FSs correctly (for whatever reason). We should really fix
> > the
> > problem there, not in the kernel.
> 
> Well, the only thing that makes me worry is a slow down because of
> using this service - besides that, this would be the perfect solution.
> Would it be possible to have it export the MIME type extension table to
> the Storage Kit?

Probably. Though that would only be the second best solution.

> If I understand you correctly, you would fix BNodeInfo to ask the
> roster about the type for the given file - I am not sure if it's a good
> idea to do a full lookup there, though (again, speed considerations).

No, I don't think I would change BNodeInfo. For a node on a FS that doesn't 
support attributes or MIME types, the Tracker shouldn't even try to get 
data from a BNodeInfo object, but instead sniff the type and get the info 
from BMimeType.

> If I open up a folder with thousand files, how much slower will it get
> because of that?

Don't know. But, unless I'm mistaken here, the Tracker currently lazily 
gets the information when needed (i.e. when an entry is about to be 
displayed). So I wouldn't expect a significant slow-down when opening a 
large folder, since there's only overhead for the visible entries. But to 
be sure this needs to be verified by tests. If it is slow indeed, the 
sniffing can as well be done as a background task.

> Anyway, in whatever way we will solve this, I think this is something
> we should definitely do before R1.

Yep.

CU, Ingo