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

[Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>]

FWIW at this late point in the game...

I don't really like the idea of putting the mime types in the kernel. Mostly 
for the reasons that Ingo says. But also because I think that the kernel should 
do only what only the kernel can do. In other words, without trying to be 
extreme, I think that the smaller and tighter the kernel is, the better. 

That isn't to say a micro-kernel or anything, but a monolithic kernel that 
provides only the most necessary of services. 

With hyper threading (an idea that I think will die) and multi-cores (an idea 
that I think will thrive) not to mention multi-processor machines becoming more 
prevelent (esp on the PPC side), it seems to me that there may well be a lot 
more circumstances where you will have both the user land side (Registrar in 
this case) and kernel land active at the same time. That would be a very ideal 
situation for this particular situation.

 
On 2005-01-06 at 11:08:58 [-0500], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > No, it can't, since you generally can't get the name of a node.
> > > Also keep in mind BNode stuff might get used without a valid 
> > > BApplication/BRoster.
> > Our be_roster is initialized at libbe initialization time. All registrar 
> > services (MIME types, clipboard, message runners, etc.) are available 
> > without a BApplication.
> 
> Oh, that's great!
> 
> > > Trackers sniffs files when:
> > > - you right-click them and select the "Open With" submenu,
> > > - you dbl click
> > > - you start moving the selection
> > > - you use "Identify".
> > > 
> > > The problem currently, and you can see it even on BFS sometimes, is it 
> > > asks the roster to sniff the file, then reads the BEOS:TYPE attribute.
> > > But with RO fs that won't work, and sometimes even on BFS the roster is
> > > too late in writing the attribute, and Tracker tells you "Unable to find 
> > > an app...", even though you see the icon changed and the file has
> > > been sniffed. Actually dbl-clicking it the next time will bring the 
> > > correct app.
> > Weird. One would think the Tracker uses the `synchronous' flag of 
> > update_mime_info(). Anyway, as you say, for RO FSs there must be another 
> 
> Wherever the bug is, this doesn't seem to be Tracker's fault; at least it 
> really calls update_mime_info() in synchronous mode, I just checked it.
> 
> > solution anyway (same for FSs that don't support MIME types/ attributes). 
> > In 
> > those cases the Tracker can just use BMimeType::GuessMimeType() directly.
> 
> But there as well, it would be great if the icon for the file is already 
> correct - and I would still assume that a full lookup is to expensive there.
> 
> > > > > 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
> > > > > :)
> > > /me pets union-mount
> 
> Dunno, haven't seen it in action yet :)
> 
> > > Now, about FAT: OS/2 and Cygwin use a file named EA DATA.SF to store
> > > extended atributes, probably we could use such a file as well. 
> > > http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
> > If there's a interoperable way to use it, this is certainly a good idea.
> 
> http://www.tavi.co.uk/os2pages/eadata.html
> From what I found an EA data entry comes with a name and a data field which 
> can be arbitrary data. Looks like we could use it. Another use of these 
> attributes is for standard POSIX permission sets (that's what Cygwin is using 
> it for).
> 
> Bye,
>    Axel.