[interfacekit] Re: MimeDatabase
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Wed, 21 Aug 2002 04:00:19 -0700
> 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.
That used to happen to me reasonably often, actually. IIRC, I'd get the
little mailbox icon in the Deskbar indicating new mail, but nothing
would show up in my live queries (one of which was "all mail")...
> > > 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.
Sounds good.
> 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 =60app 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.
I believe you are correct about this. The only thing I can see
create_app_meta_mime() doing so far is mapping the info from the given
file into the database.
> Then there is
> =60__mime_table' which is certainly also held in memory to speed up
> BMimeType::GetSupportingTypes().
I'm still a bit perplexed about __mime_table. I honestly think it's
left over from days gone past. It contains *some* supporting app
information, but not nearly all of it. You have to go through the
actual database and read through the META:FILE_TYPES attributes of all
the application types and merge that information with the __mime_table
information to get the full supporting apps list.
I still don't know how information gets added to the __mime_table file
though. As best I've been able to tell, create_app_meta_mime() doesn't
do it. Only one of the installed OpenBeOS preference application
signatures has made its way into my __mime_table file
(application/x-vnd.OBOS-KBRD), whereas all of them are represented in
my mime database. Why? I don't know.
Aside from being sure to check the __mime_table file for supporting
apps info, I don't know that I see much point in trying to support it
any further.
> 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()
Definitely.
> (watch out
> the private BMimeType::{Set,Get}SupportedTypes(), that we may or may
> not want to implement as well).
We may as well. I don't really see any reason why they should be
private anyway.
Now, as to the non-atomic BMimeType::Get() functions:
+ GetInstalledTypes(BMessage*)
Needs a list of all installed types (including supertypes)
+ GetInstalledTypes(const char*, BMessage*)
Needs a list of all the installed types for each supertype
+ GetInstalledSupertypes(BMessage*)
Needs a list of all the installed supertypes
+ GetSupportingApps(BMessage*)
Needs a list of all the supporting application signatures
for each installed type.
Since there's only one copy of the database loaded on any machine at
any given time, I'm assuming we want to optimize completely for speed.
In that case, here's what I'm thinking I'll do:
// For GetInstalledTypes(BMessage*)
std::set<char*> fAllInstalledTypes;
BMessage *fAllTypesMessage;
// For GetInstalledTypes(const char*, BMessage*)
// and GetInstalledSupertypes(BMessage*)
struct InstalledSubtypesInfo {
=09std::set<char*> fInstalledSubtypes;
=09BMessage *fCachedMessage;
};
std::map<char*, InstalledSubtypesInfo> fSupertypesMap;
// For GetSupportingApps(BMessage*)
struct SupportingAppsInfo {
=09std::set<char*> fSupportingApps;
=09BMessage *fCachedMessage;
};
std::map<char*, SupportingAppsInfo> fSupportingAppsMap;
Initially, just the maps and sets would be filled with data. When a
function is called, first the appropriate cached BMessage would be
checked. If it existed, it'd be returned. If not, a new BMessage would
be constructed from the data in the maps and sets and then returned and
cached. If, by a Set() or Delete() call, the data in the maps and sets
would need to be updated, any corresponding cached BMessage(s) would be
deleted.
Also, it might be reasonable to get rid of fAllInstalledTypes and just
get that information from the keys of fSupportingAppsMap.
Thoughts?
-Tyler
Other related posts:
