[openbeos] Re: kernel mime_table module
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 09 Jan 2005 18:24:08 +0100
On 2005-01-09 at 17:53:54 [+0100], Axel Dörfler wrote:
> 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.
As François proposed, storing an entry_ref with the FD should help.
Otherwise, as I wrote, getting any file name at all might not be possible
without iterating through the whole volume.
> > > 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.
OK, good point.
> 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.
Unfortunately currently the file name extensions are used only for the
second guess. At least that's how I believe we have implemented it. :-)
The MIME sniffer rules have priorities, but the extensions haven't.
> > > 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).
As a first approximation, yes. Though ideally not the individual
applications should cache the icons, but some system service. So it would
make most sense to provide cache access functions via libbe (or some
separate library) and let the Tracker use them as well.
CU, Ingo
Other related posts:
