
|
[openbeos]
||
[Date Prev]
[01-2005 Date Index]
[Date Next]
||
[Thread Prev]
[01-2005 Thread Index]
[Thread Next]
[openbeos] Re: kernel mime_table module
- From: "shatty" <shatty@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 04 Jan 2005 10:54:56 -0800
I'm glad to see this issue being brought up.
Long ago I started modifying my local copying
of dosfs to support using the beos_mime entries
in order to resolve types. I was planning to
use only extensions, not sniffing.
Also I figured that BMimeType should grow a
method to do an extension to type conversion.
There is this comment in the BeBook which
just seems overly unfortunate to me:
"Also, there's no way to ask the database to
give you a set of file types that map to a
given extension. To find a type for an
extension, you have to get all the installed
types with GetInstalledTypes() and ask each
one for its set of extensions."
Anyway, I never did get to anything really
worth sharing.
I hope that any solution offers consistency
between the BMimeType and what the file
systems offer. It seems to me that the
number of types is sufficiently small that
we should be able to maintain a lookup table
in memory at all times. Perhaps we need to
use node monitoring to keep it up to date.
I'm glad to see that someone is working on
this issue. :-)
Andrew
-----Original Message-----
From: "Axel DÃrfler" <axeld@xxxxxxxxxxxxxxxx>
To: openbeos@xxxxxxxxxxxxx
Date: Tue, 04 Jan 2005 18:38:57 +0100 CET
Subject: [openbeos] Re: kernel mime_table module
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?
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).
If I open up a folder with thousand files, how much slower will it get
because of that?
Anyway, in whatever way we will solve this, I think this is something
we should definitely do before R1.
Bye,
Axel.
|

|