[interfacekit] Re: MimeDatabase
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Fri, 23 Aug 2002 01:15:21 CEST (+0200)
> 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:
