I looked yesterday at storing the entire extension state, including
its manifest in the preferences. This is desirable because it will
reduce disk IO at startup and eliminate some kinds of races that we
have today.
I decided not to do this now because it ended up being orthogonal to
the feature I'm working on, but I wanted to write down what I came up
with in case someone else gets to it before me.
a) I think it is important to not break the extension system with this
mod, so that means that for awhile (1 or 2 dev channel releases?) we
will both write the entire manifest to the prefs and load from disk
normally.
b) Extension prefs are currently written in
ExtensionsService::OnExtensionInstalled. At this point, we no longer
have the JSON form of the manifest, it has already been parsed into an
Extension object.
c) In order to avoid breaking backward compat, we also need to write
the prefs at ExtensionsService::OnExtensionsLoaded. At this point, we
also do not have the JSON anymore, only Extension objects.
b) and c) lead me to the conclusion that we should refactor the
Extension class so that it is a lightweight wrapper around a JSON
dictionary and has no state of its own. This would fix the problem of
not having access to the JSON representation and therefore having to
write serialization code for it.
At the same time we could decouple validation from the Extension class
into an ExtensionManifestValidator thing. The contents of the manifest
have at this point diverged pretty far from the static state of an
extension post-installation and I think they should be separate
concerns.
Thoughts?
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
