[interfacekit] Re: MimeDatabase
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Wed, 21 Aug 2002 23:52:50 CEST (+0200)
> > 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.
Not so on my machine. I attached my little test apps. The one reads and
prints out __mime_table, the other uses BMimeType::GetInstalledTypes()/
GetSupportingApps(). __mime_table list only apps that support the
actual subtype, not just the supertype, and it does not contain types
that aren't supported by any app. If one also removes the not (longer)
installed types, then both lists are perfectly equal. As said above,
this holds at least for my installation.
Therefore my conclusion is, that __mime_table 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
__mime_table instead.
> 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.
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 __mime_table. The file is
only written on shutdown and probably now and then whilst running.
> 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.
From the preference applications I just checked (not all though, due to
my general laziness ;-) only Keymap supports a type at all (application
/x-vnd.Be-kmap). By accident Keymap has the same signature as Keyboard,
which is the one you encountered.
> 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.
As written above, I think, __mime_table shortens the time for booting.
We might test, if it is much -- my certainly small MIME DB has 257
application/* entries, which all had to be checked for META:FILE_TYPES,
perhaps taking one or two seconds, I reckon -- but I don't see the
reason for abandoning it.
What we should do, is to remove entries from __mime_table, that are not
longer installed in the MIME DB. At least I don't see any reason not to
do it. There seems to be no way to get hold of the not installed types
contained in __mime_table anyway.
> > (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.
The explanation that immediately comes to my mind is, that it should
not be allowed to manipulate the types an app supports algorithmically.
In fact this doesn't make much sense, as an app either supports a type
or it does not. One may be able to construct counter examples though.
E.g. when an application supports types through add-ons (a web browser
for instance). I don't know, if BMimeType::SetSupportedTypes() was the
best means in this case, as the type support is a static feature
whereas loading add-ons is done at run time. I think, a better solution
would be to make the add-on an executable, itself supporting the type.
When a file of the type is requested to be opened, the add-on gets
executed and it simply passes the entry_ref to the main application
(e.g. using BRoster::Launch() and quitting thereafter).
To sum it up, I vote for leaving the methods private for the time
being, and, if we find a good reason to make it public, we can do that
at any time.
> 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.
Yep, sounds reasonable.
> 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;
First for sake of formal correctness (feel free to call it pettiness):
string should be used instead of char* (as it wouldn't work, unless
there is a specialization for it) and the struct members should be
named x_y_z instead of fXYZ.
> 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.
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...
> Also, it might be reasonable to get rid of fAllInstalledTypes and
> just
> get that information from the keys of fSupportingAppsMap.
Yep, sounds logical.
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.
CU, Ingo
-- Attached file included as plaintext by Ecartis --
Content-Transfer-Encoding: base64
Content-Disposition: Attachment
Content-Type: text/x-source-code; name=mime-table-list-file.cpp
Ly8gbWltZS10ZXN0LmNwcAoKI2luY2x1ZGUgPGFsZ29yaXRobT4KI2luY2x1ZGUgPHN0ZGlvLmg+
CiNpbmNsdWRlIDx2ZWN0b3I+CgojaW5jbHVkZSA8QXBwRmlsZUluZm8uaD4KI2luY2x1ZGUgPEFw
cGxpY2F0aW9uLmg+CiNpbmNsdWRlIDxCaXRtYXAuaD4KI2luY2x1ZGUgPEVudHJ5Lmg+CiNpbmNs
dWRlIDxNZXNzYWdlLmg+CiNpbmNsdWRlIDxNZXNzYWdlUXVldWUuaD4KI2luY2x1ZGUgPE1lc3Nl
bmdlci5oPgojaW5jbHVkZSA8TWltZS5oPgojaW5jbHVkZSA8U3RyaW5nLmg+CgpzdHJ1Y3QgbXNn
X2ZpZWxkX2luZm8gewoJY2hhcgkJKm5hbWU7Cgl0eXBlX2NvZGUJdHlwZTsKCWludDMyCQljb3Vu
dDsKfTsKCi8vIDwKYm9vbApvcGVyYXRvcjwoY29uc3QgbXNnX2ZpZWxkX2luZm8gJmluZm8xLCBj
b25zdCBtc2dfZmllbGRfaW5mbyAmaW5mbzIpCnsKCWludCBuID0gc3RyY21wKGluZm8xLm5hbWUs
IGluZm8yLm5hbWUpOwoJcmV0dXJuIChuIDwgMAoJCQl8fCBuID09IDAKCQkJICAgJiYgKGluZm8x
LnR5cGUgPCBpbmZvMi50eXBlCgkJCQkgICB8fCBpbmZvMS50eXBlID09IGluZm8yLnR5cGUKCQkJ
CQkgICYmIGluZm8xLmNvdW50IDwgaW5mbzIuY291bnQpKTsKfQoKLy8gbWFpbgppbnQKbWFpbigp
CnsKCS8vIG9wZW4gZmlsZSAiX19taW1lX3RhYmxlIiBhbmQgdW5mbGF0dGVuIHRoZSBCTWVzc2Fn
ZSBmcm9tIGl0CglzdGF0dXNfdCBlcnJvciA9IEJfT0s7Cgljb25zdCBjaGFyICptZXRhTWltZUZp
bGUKCQk9ICIvYm9vdC9ob21lL2NvbmZpZy9zZXR0aW5ncy9iZW9zX21pbWUvX19taW1lX3RhYmxl
IjsKCUJGaWxlIGZpbGUobWV0YU1pbWVGaWxlLCBCX1JFQURfT05MWSk7CgllcnJvciA9IGZpbGUu
SW5pdENoZWNrKCk7CglCTWVzc2FnZSBtZXNzYWdlOwoJaWYgKGVycm9yID09IEJfT0spCgkJZXJy
b3IgPSBtZXNzYWdlLlVuZmxhdHRlbigmZmlsZSk7CgkvLyBnZXQgYSBsaXN0IG9mIHRoZSBtZXNz
YWdlIGZpZWxkcyAodGhlIHN1cHBvcnRlZCB0eXBlcykKCXZlY3Rvcjxtc2dfZmllbGRfaW5mbz4g
aW5mb3M7CglpZiAoZXJyb3IgPT0gQl9PSykgewoJCW1zZ19maWVsZF9pbmZvIGluZm87CgkJZm9y
IChpbnQzMiBpID0gMDsKCQkJIG1lc3NhZ2UuR2V0SW5mbyhCX1NUUklOR19UWVBFLCBpLCAmaW5m
by5uYW1lLCAmaW5mby50eXBlLAoJCQkgCQkJCSAmaW5mby5jb3VudCkgPT0gQl9PSzsKCQkJIGkr
KykgewoJCQlpbmZvcy5pbnNlcnQoaW5mb3MuZW5kKCksIGluZm8pOwoJCX0KCX0KCS8vIHNvcnQg
dGhlIGxpc3QKCXNvcnQoaW5mb3MuYmVnaW4oKSwgaW5mb3MuZW5kKCkpOwoJLy8gaXRlcmF0ZSB0
aHJvdWdoIHRoZSBvcmRlcmVkIGxpc3QgYW5kIGdldCB0aGUgc3VwcG9ydGluZyB0eXBlcyBmcm9t
CgkvLyB0aGUgbWVzc2FnZQoJaW50MzIgY291bnQgPSBpbmZvcy5zaXplKCk7Cglmb3IgKGludDMy
IGkgPSAwOyBpIDwgY291bnQ7IGkrKykgewoJCWNvbnN0IG1zZ19maWVsZF9pbmZvICZpbmZvID0g
aW5mb3NbaV07Ci8vaWYgKEJNaW1lVHlwZShpbmZvLm5hbWUpLklzSW5zdGFsbGVkKCkpIHsKCQlw
cmludGYoIiVzOlxuIiwgaW5mby5uYW1lKTsKCQlmb3IgKGludDMyIGsgPSAwOyBrIDwgaW5mby5j
b3VudDsgaysrKSB7CgkJCUJTdHJpbmcgdHlwZTsKCQkJaWYgKG1lc3NhZ2UuRmluZFN0cmluZyhp
bmZvLm5hbWUsIGssICZ0eXBlKSA9PSBCX09LKQoJCQkJcHJpbnRmKCIgICVzXG4iLCB0eXBlLlN0
cmluZygpKTsKCQl9Ci8vfQoJfQoJcmV0dXJuIDA7Cn0KCg==
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-be_attribute
-- File: BeOS Attributes
-- Attached file included as plaintext by Ecartis --
Content-Transfer-Encoding: base64
Content-Disposition: Attachment
Content-Type: text/x-source-code; name=mime-table-list.cpp
Ly8gbWltZS10ZXN0LmNwcAoKI2luY2x1ZGUgPGFsZ29yaXRobT4KI2luY2x1ZGUgPHN0ZGlvLmg+
CiNpbmNsdWRlIDxzdHJpbmc+CiNpbmNsdWRlIDx2ZWN0b3I+CgojaW5jbHVkZSA8QXBwRmlsZUlu
Zm8uaD4KI2luY2x1ZGUgPEFwcGxpY2F0aW9uLmg+CiNpbmNsdWRlIDxCaXRtYXAuaD4KI2luY2x1
ZGUgPEVudHJ5Lmg+CiNpbmNsdWRlIDxNZXNzYWdlLmg+CiNpbmNsdWRlIDxNZXNzYWdlUXVldWUu
aD4KI2luY2x1ZGUgPE1lc3Nlbmdlci5oPgojaW5jbHVkZSA8TWltZS5oPgojaW5jbHVkZSA8U3Ry
aW5nLmg+CgovLyBtYWluCmludAptYWluKCkKewoJQkFwcGxpY2F0aW9uIGFwcCgiYXBwbGljYXRp
b24veC12bmQuYm9uZWZpc2gtbWltZS10YWJsZS1saXN0Iik7CgkvLyBnZXQgdGhlIGluc3RhbGxl
ZCB0eXBlcwoJc3RhdHVzX3QgZXJyb3IgPSBCX09LOwoJQk1lc3NhZ2UgaW5zdGFsbGVkVHlwZXM7
CgllcnJvciA9IEJNaW1lVHlwZTo6R2V0SW5zdGFsbGVkVHlwZXMoJmluc3RhbGxlZFR5cGVzKTsK
CS8vIHB1dCB0aGUgc3VwcG9ydGVkIHR5cGVzIGludG8gYSBsaXN0IGFuZCBzb3J0IHRoZSBsaXN0
CglpZiAoZXJyb3IgPT0gQl9PSykgewoJCXZlY3RvcjxzdHJpbmc+IHN0cmluZ3M7CgkJQlN0cmlu
ZyB0eXBlU3RyaW5nOwoJCWZvciAoaW50MzIgaSA9IDA7CgkJCSBpbnN0YWxsZWRUeXBlcy5GaW5k
U3RyaW5nKCJ0eXBlcyIsIGksICZ0eXBlU3RyaW5nKSA9PSBCX09LOwoJCQkgaSsrKSB7CgkJCXN0
cmluZ3MuaW5zZXJ0KHN0cmluZ3MuZW5kKCksIHN0cmluZyh0eXBlU3RyaW5nLlN0cmluZygpKSk7
CgkJfQoJCXNvcnQoc3RyaW5ncy5iZWdpbigpLCBzdHJpbmdzLmVuZCgpKTsKCQkvLyBpdGVyYXRl
IHRocm91Z2ggdGhlIG9yZGVyZWQgbGlzdCBhbmQgZ2V0IHRoZSBzdXBwb3J0aW5nIHR5cGVzIGZv
cgoJCS8vIGVhY2ggdHlwZQoJCWludDMyIGNvdW50ID0gc3RyaW5ncy5zaXplKCk7CgkJZm9yIChp
bnQzMiBpID0gMDsgaSA8IGNvdW50OyBpKyspIHsKCQkJY29uc3QgY2hhciAqdHlwZVN0cmluZyA9
IHN0cmluZ3NbaV0uY19zdHIoKTsKCQkJLy8gZ2V0IHRoZSBzdXBwb3J0aW5nIHR5cGVzCgkJCUJN
aW1lVHlwZSB0eXBlKHR5cGVTdHJpbmcpOwoJCQlCTWVzc2FnZSBzdXBwb3J0aW5nQXBwczsKCQkJ
dHlwZS5HZXRTdXBwb3J0aW5nQXBwcygmc3VwcG9ydGluZ0FwcHMpOwoJCQkvLyBpZiBpdCBpcyBh
IHN1cGVyIHR5cGUsIHByaW50IGFsbCBzdXBwb3J0aW5nIHR5cGVzLCBvdGhlcndpc2UKCQkJLy8g
b25seSB0aGUgb25lcyBzdXBwb3J0aW5nIHRoZSBzdWJ0eXBlCgkJCWludDMyIHN1YkNvdW50OwoJ
CQlpZiAodHlwZS5Jc1N1cGVydHlwZU9ubHkoKSkgewoJCQkJaWYgKHN1cHBvcnRpbmdBcHBzLkZp
bmRJbnQzMigiYmU6c3VwZXIiLCAmc3ViQ291bnQpICE9IEJfT0spCgkJCQkJc3ViQ291bnQgPSAw
OwoJCQl9IGVsc2UgewoJCQkJaWYgKHN1cHBvcnRpbmdBcHBzLkZpbmRJbnQzMigiYmU6c3ViIiwg
JnN1YkNvdW50KSAhPSBCX09LKQoJCQkJCXN1YkNvdW50ID0gMDsKCQkJfQoJCQkvLyBwcmludCB0
eXBlIGFuZCBpdHMgc3VwcG9ydGluZyB0eXBlcwoJCQlpZiAoc3ViQ291bnQgPiAwKQoJCQkJcHJp
bnRmKCIlczpcbiIsIHR5cGVTdHJpbmcpOwoJCQlCU3RyaW5nIGFwcDsKCQkJZm9yIChpbnQzMiBr
ID0gMDsKCQkJCSBrIDwgc3ViQ291bnQKCQkJCSAmJiBzdXBwb3J0aW5nQXBwcy5GaW5kU3RyaW5n
KCJhcHBsaWNhdGlvbnMiLCBrLCAmYXBwKSA9PSBCX09LOwoJCQkJIGsrKykgewoJCQkJcHJpbnRm
KCIgICVzXG4iLCBhcHAuU3RyaW5nKCkpOwoJCQl9CgkJfQoJfQoJcmV0dXJuIDA7Cn0KCg==
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-be_attribute
-- File: BeOS Attributes
Other related posts:
