[interfacekit] Re: MimeDatabase

Weird, this mail just appeared in my new mails query after booting. The 
live query update message apparently got lost when it was fetched from 
my account earlier this day.

> > BTW, I finished the work on BNodeInfo. The tests are complete and 
> > the
> > implementation passes them. The class is not included in the build 
> > yet,
> > as it wouldn't work well with a partial BMimeType implementation. I
> > will add it as soon as all needed features are available.
> 
> In addition to everything else I mentioned earlier, 
> BMimeType::IconForType() should work now as well. Was there anything 
> else you needed (I'm tired and it's late, else I'd try it myself 
> :-)?

Cool. No, IIRC only GetPreferredApp(), GetIcon() and GetIconForType() 
are needed for BNodeInfo. But as BAppFileInfo needs some more methods 
and will itself communicate with the registrar, I guess -- not 
completely sure yet, still investigating -- it doesn't make that much 
sense to add it to the build now anyway. I will come back with this 
topic when I actually start implementing BAppFileInfo and something is 
missing. But, I suppose, you will be done earlier.

Just to prevent you running out of work: You might also want to think 
about what additional MIME database related structures we need to 
maintain in the registrar. The quite vague `app meta MIME' comes to my 
mind, but I suspect, it will turn out, that this just denotes the sum 
of application specific MIME data (supported types, icons for 
types,...) only stored in attributes as the other data. Then there is 
`__mime_table' which is certainly also held in memory to speed up 
BMimeType::GetSupportingTypes(). This map must be kept in sync when 
changes to the database are done. I think, this does basically concern 
BMimeType::Delete() and BAppFileInfo::SetSupportedTypes() (watch out 
the private BMimeType::{Set,Get}SupportedTypes(), that we may or may 
not want to implement as well).

CU, Ingo

Other related posts: