[openbeos] Re: kernel mime_table module
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 05 Jan 2005 02:21:25 +0100
On 2005-01-04 at 21:56:49 [+0100], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > 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.
>
> I would chose BNodeInfo as a starting point, as this class is the one
> that abstracts the file type stuff from the implementation.
Well, the `abstraction' is very direct. The properties it can get/set are
directly stored as is in the node's attributes. There's little magic here.
> Whenever a file does not have the BEOS:TYPE attribute set (for whatever
> reason), it could get the type via the file extension only.
No, it can't, since you generally can't get the name of a node.
> This way, all applications would benefit from this -- why should we aim
> for a Tracker only solution here (or at least have all applications do
> this extra work)?
Certainly it would be nice to extend the API to solve the problem for all
applications -- though I suppose, if we make sure Tracker and BRoster
(FindApp(), Launch()) work fine, there are few apps left that suffer from
it -- but BNodeInfo is not the right place, and I'm not sure at the moment
what else would be. Maybe something alongside BMimeType::GuessMimeType(),
but I can't say that I particularly like this.
> > > 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.
>
> I am not sure when Tracker does this; I would guess that it only loads
> additional attributes on demand, but not determine the file type this
> way.
Yes, you're right. Looks like the MIME type is obtained when opening the
Model. But I suppose it shouldn't be impossible to change it to initialize
it to the generic file type for FSs that don't support attributes/MIME
types and fix it later when needed or in the background.
> > > Anyway, in whatever way we will solve this, I think this is
> > > something
> > > we should definitely do before R1.
> > Yep.
>
> After R1, I want to introduce file system layers, so that we can just
> plug in generic attribute support for all file systems that don't
> support them natively. That should also simplify a couple of things :)
That sounds nice.
CU, Ingo
Other related posts:
