[openbeos] Re: kernel mime_table module

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 09 Jan 2005 16:44:16 +0100

On 2005-01-09 at 04:02:36 [+0100], Axel Dörfler wrote:
> 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.

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.

> > > 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 :)

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.

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

CU, Ingo

Other related posts: