[openbeos] Re: kernel mime_table module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 09 Jan 2005 17:53:54 +0100 CET
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
[BNodeInfo]
> > > > 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.
> Unless the FS doesn't support hard links, this sounds impracticable,
> since
> you might simply have more than one name for a node, and the FS might
> not
> be able to get all (or even any) of them without potentially
> iterating
> through all the volume's entries.
For this very use case, that wouldn't matter at all - any link would
do.
> > 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 :)
> And I suppose, I wouldn't really like it either. I find it quite
> reasonable
> that MIME type, preferred app, icon and the like are only associated
> with
> the node, since the node makes up the whole contents (data and
> attributes)
> while file names are just names and many can exist for one node.
Unfortunately, that's not quite true - the file name is an important
part of the whole, too. Just consider OpenOffice documents that would
just look like Zip-Archives without their suffix. I would really doubt
that you'd like BeOS to open Expander on these files instead of that
office suite.
Furthermore, the file name allows you to rapidly look up a very
reliable file type.
I'm afraid that you need both, the contents and the file name to make a
complete prediction that's not too expensive.
> > 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).
> Good idea.
Unless we introduce an icon cache into libbe.so, it makes probably the
most sense to put the retrieval function into libbe.so, and have
Tracker call it itself (and then put those into its cache).
Bye,
Axel.
Other related posts:
