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

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > 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.

I know, but that alone is not a reason to keep it that way. The 
abstraction *is* there, we could just as well use it.

> > 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.

The kernel can do this, or at least it could do this if we need to.

> > 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.

Actually, I think you're not wrong - but that's probably because the 
BNodeInfo class is a bit messed up. A BEntryInfo class would be what 
would better fit in here, and yet, that one doesn't exist :)
In any way, if, as you say, Tracker and BRoster would support this, 
this would probably really cover most use cases. But what we could do 
eventually, is having BNodeInfo::GetTrackerIcon() actually use 
libtracker.so (and its icon cache) for retrieving the icon or maybe 
vice versa (because right now, the results aren't consistent between 
those two).

> > 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.

Although it obviously adds complexity, it might be worth it.

> > 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.

Definitely, like so many other things :-)

Bye,
   Axel.