[interfacekit] Re: MimeDatabase

> On 2002-08-21 at 14:52:50 [-0700], interfacekit@xxxxxxxxxxxxx wrote:

> > Not so on my machine. 
> [...]
> > Therefore my conclusion is, that =5F=5Fmime=5Ftable is not just legacy, 
> > but
> > is useful to speed up the boot process -- when the registrar is
> > started, it doesn't need to scan the database for applications'
> > supported types and build the reverse mapping, but it can just read 
> > in
> > =5F=5Fmime=5Ftable instead.
> 
> That would make sense. I'm still not sure why I've been unable to add 
> entries to my copy (I've tried rebooting, I've tried BEOS:FILE=5FTYPES 
> resources as in the keymap preflet...), but it's possible I'm just 
> not 
> getting the formula right.

Mmh, I've just tried it, and it worked exactly as I expected: The app 
had a signature and a supported file type set in the resources. After 
launching it from the Tracker, its signature appeared in the list 
retrieved via BMimeType::GetSupportingApps(), but not in =5F=5Fmime=5Ftable. 
I immediately rebooted and voil=E0 it also found its way into the latter.

> > > I still don't know how information gets added to the =5F=5Fmime=5Ftable
> > > file
> > > though. As best I've been able to tell, create=5Fapp=5Fmeta=5Fmime()
> > > doesn't
> > > do it.
> > 
> > I believe it does. Not directly though -- it sends a message to the
> > registrar and the "mime updater" does the job, certainly using
> > BAppFileInfo, which uses BMimeType::SetSupportedTypes(), which in 
> > turn
> > does the change to the in-memory version of =5F=5Fmime=5Ftable. The file 
> > is
> > only written on shutdown and probably now and then whilst running.
> 
> Like I mentioned, I've tried rebooting, and to no effect. The 
> information shows up in the database, but not =5F=5Fmime=5Ftable... I think 
> I 
> have a lazy registrar.

Lazy employees... you should fire it and hire a new one. ;-)

> I just don't see that supported types are all that different from the 
> other attributes BMimeType gives access to. And certainly, why would 
> we 
> want to keep someone from being able to at least lookup the types 
> supported by a given app=3F It seems highly inconsistent to me to give 
> unlimited access to the rest of the database through BMimeType but 
> then 
> exclude supported types. And code-wise, they're essentially no 
> different from Get/SetFileExtensions() or Get/SetAttrInfo(). A little 
> more code will be needed to update the supported apps table, but not 
> so 
> much that it justifies making those methods private (plus, assuming 
> BAppFileInfo implements SetSupportedTypes() functionality, we'll have 
> to do it anyway... :-). 
> 
> So any way, my vote's for making them public. Like you said though, 
> it's not like it'll be a lot of work to change them one way or the 
> other :-).

That's true only for one direction. Once it has been public in a 
release it can't be changed back to private without breaking source 
compatibility. While I share your opinion in principle, it makes me a 
bit unsure, that I don't know, why Be made them private. I think, they 
must have had a reason.

> Incidentally, I have Get/SetSupportedTypes() implemented but 
> not yet checked in, in case you might find them useful for 
> BAppFileInfo.

Great!

> > I'm not sure, if this invalidation+lazy-reinitialization strategy 
> > is
> > advantageous in all cases. E.g. the set of (all) installed types is
> > large, but seldomly changed. A single Install() or Delete() would
> > require to rebuild the whole message instead of just adding/
> > deleting
> > one item. There may be issues with finding the index of the type to 
> > be
> > added/removed though. Don't know...
> 
> Well, after looking BMessage over and thinking about it, I believe it 
> *would* be faster to maintain everything in BMessages. You'd need to 
> keep a mapping of mimetypes to indices in the BMessage. Adding would 
> be 
> easy, but deleting would require an update of the indices in the map 
> for all the mimetypes following the type removed. Overall it's still 
> O(n), but decrementing O(n) integers in memory should be considerably 
> faster than walking through the entire database again on disk. It'll 
> be 
> a bit more complicated, too, but I bet it would be worth it.
> 
> I have GetInstalledTypes(BMessage*) done using the method I 
> originally 
> mentioned, so perhaps I'll reimplement it using this BMessage method 
> and see which is really faster before finishing everything else.

Please let's postpone this, as all optimizations, until more important 
things have been done.

> > I'd like to propose to encapsulate all this functionality into a
> > separate class. If its interface is designed cleverly, we are free 
> > to
> > play with its guts afterwards.
> 
> Done. :-) The interface I'm currently using is essentially identical 
> to 
> that from BMimeType:

Alright, then just leave it like that for the time being. A time will 
come, when we can fine-tune any aspect we've neglected. :-P

CU, Ingo

Other related posts: