Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 47327 Allow extensions/apps to sync their own settings
Starred by 491 users Project Member Reported by annapop@chromium.org, Jun 23, 2010 Back to list
Status: Fixed
Owner: kalman@chromium.org
Closed: Dec 2011
Cc: akalin@chromium.org, jochen@chromium.org, kalman@chromium.org, aa@chromium.org, finnur@chromium.org, erikkay@chromium.org
Components:
OS: ----
Pri: 1
Type: Feature

Blocking:
issue 30224

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
ENVIRONMENT
Google Chrome	6.0.445.0 (Official Build 50456) dev
WebKit	534.1
V8	2.2.18
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.445.0 Safari/534.1
Command Line	 /opt/google/chrome/google-chrome

REPRO STEPS
0. Two machines A and B, with the latest Chrome build installed, both 
clients online and connected to sync server with the same account;
1. On client A: Navigate to Wrench -> Extensions; 
2. A: install a random extension that is known to have extension specific options (e.g. Google Translate);
3. A: Click on 'Options' and customize;
4. B: Navigate to Wrench -> Extensions and click on 'Options' for the extension from step 2.

ACTUAL RESULTS
Extension is synced properly, however the Options are not.

EXPECTED RESULTS
Expected that all extension related options will be synced as well. 

ADDITIONAL INFORMATION
'Allow in incongito' is synced.
 
Comment 1 by akalin@chromium.org, Jun 23, 2010
Labels: Mstone-7
At least for V1, extension options won't be synced.
Comment 2 by n...@chromium.org, Jun 23, 2010
Labels: -Area-Undefined Area-Internals
Status: Available
Comment 3 by erikkay@chromium.org, Jun 30, 2010
Labels: Feature-Extensions
Comment 4 by tim@chromium.org, Aug 24, 2010
Labels: -Mstone-7 Mstone-X
Comment 5 by akalin@chromium.org, Aug 30, 2010
Labels: SyncEverything
Comment 6 by satoshi....@gmail.com, Aug 30, 2010
Issue 53835 has been merged into this issue.
Comment 7 by lara...@gmail.com, Aug 30, 2010
This is needed. Having 50-55 extensions on my heavy version of Chrome (Beta channel), it can take 30 minutes or 1 hour to go through all the damn settings. Maybe having some sort of an options page by Google that's universal across all extensions can make syncing easier to do. This is a major annoyance of Chrome.
Comment 8 by tal.re...@gmail.com, Aug 31, 2010
do not copy all the extension on the server.
just keep an ini file - a setting file to each extension that the author of the extension will save the setting there. 
Comment 9 by akalin@chromium.org, Sep 3, 2010
Issue 52396 has been merged into this issue.
Issue 54618 has been merged into this issue.
Comment 11 by temp01...@gmail.com, Oct 23, 2010
Issue 60431 has been merged into this issue.
Comment 12 by aa@chromium.org, Oct 23, 2010
Labels: -Type-Bug Type-Feature
Summary: Allow extensions to sync their own settings (was: NULL)
This is working as designed, but I agree it would be cool to sync settings.

Currently developers store all kinds of things in local storage -- some of them are "settings", but some of them are probably local state that aren't appropriate to sync.

So I think we'd need to introduce a new storage area for syncable settings, distinguished from nonsyncable stored state. Developers would need to update their extensions to take advantage of the new API.
Comment 13 by phen...@gmail.com, Oct 25, 2010
Totally agree with:
"So I think we'd need to introduce a new storage area for syncable settings, distinguished from nonsyncable stored state. Developers would need to update their extensions to take advantage of the new API."
Improved upon Tal.Regev's idea. :)

I'd really like to see this up and running.
Comment 14 by tal.re...@gmail.com, Oct 25, 2010
thanks, 
if i just an opportunity to work at Google and implement that!! :]
that will be great. 
Comment 15 by gminu...@gmail.com, Nov 16, 2010
Maybe we could make properties like "__SYN_foo__" in localStorage to be synced (mimic the name convention in i18n system).

So that
localStorage["__SYN_foo__"] = "bar"
is synced, whereas
localStorage["foo"] = "bar"
isn't
Comment 16 by tal.re...@gmail.com, Nov 16, 2010
bad idea, the easy way that the author of the extension will be write to small file of ini and they will need to implement a method that will save properties and load properties, and chrome will call it when it need it.
i am sure it easy to change that API, and all the extensions author will be need to rewrite their extensions. but it will great and saver for the future. 
Comment 17 by gminu...@gmail.com, Nov 16, 2010
Hi, Tal.Regev. Could you explain more on why it's a bad idea? I'd like to hear about it.

As for your suggestions, I'm wondering why use ini files? No offence, but aren't they deprecated in most places? And I believe chrome uses sqlite to store data. Even if ini files are efficient, why suddenly introduce they just for extension sync?

I also feel that inventing new APIs should be avoided if possible.
Using an INI file or even defining which localStorage items should be synced in the manifest.json file seems like a bad idea since the developer would have to know what variables were going to be crated. This may be fine with some extensions but with something like a notes app it wouldn't be possible to know how many localStorage items would be needed.
 
How about having something like syncStorage, which would be like localStorage. Things you define in syncStorage would also appear in localStoage but would be synced. For example if syncStorage['foo'] = 'foo' was run the results would be...

syncStorage['foo']; //would be foo
localStorage['foo']; //would also be foo

...But if localStoage['foo'] = 'foo' was run the results would be...

syncStorage['foo']; //would be undefined
localStorage['foo']; //would be foo
Comment 19 by gminu...@gmail.com, Nov 16, 2010
I didn't say that these properties should be declared in manifest.json. What I meant was that if you name a property like "__SYN_foo__", then it's going to be synced, nothing else is needed. (though I'm not sure if it's feasible.)
Comment 20 by fam....@live.nl, Nov 16, 2010
The suggestion in comment 18 looks the best to me. Why?
Well, if I take a look at the AdBlock settings, they are stored like

filter_lists
  list_id
    url: X
    name: X
    user_subscribed: X
    ...
    last_updated: Y
  installed: Y
  personal_filters: X
  optional_features: X
  ...

Some items have to be synced (X), but others absolutely do not have to be synced (Y).
For example when a user updates his lists every day on computer A then it will always say it was up-to-date in computer B, even if they are never updated.
Merging two arrays together manually would be pretty hard and will cost additional time. Especially as the filter list is synced, but the update time shouldn't be synced. This however, if a user (un)subscribes from/to a filter on computer A then computer B will have an issue as a filter list does no longer exist but the data is still stored... (a non-synced setting may depend on a synced setting is all I want to demonstrate here)
For this having two functions (syncStorage and localStorage) would be a great solution.

Just my opinion, sorry for the spam
Comment 21 by tal.re...@gmail.com, Nov 16, 2010
i think if you do your suggestion, the author will need to 
rewrite their extensions. so it like my idea, but not all the extensions
have a specific design to save their properties, and if there will be
in chrome a button that the user want to save all the properties of the extensions now,
he will need to call all the sync function? and if they don't write what they need
for now? and if they do another things? how you ensure that they save all current 
properties now? if you have a global function to all the extension that they save
the option of the extensions now, it will easier to chrome to sync to the server.
think about that. and if you think my idea is bad? you can write your opinion too :]
it very easy to 
i don't care if there it will be ini of an encrypted file, the i just want to
make idea to simple to understand. 
Comment 22 by aa@chromium.org, Nov 18, 2010
I hit this today after installing StayFocusd and setting it up at home only to realize that i was going to have to set it up 3 more times.

So I started thinking about it.

I think a good first cut could be to expose something like chrome.extension.settings, which just returns an HTML5 storage tree.

We would sync this tree as one atomic unit, last update wins. So for the case of StayFocusd, there are these bits of settings that need to be synced:

1. The list of sites to block
2. The amount of time to allow
3. The time of day to reset the allowed time

Anytime any of these are written to, we sync the entire block of settings.

We would probably want to reserve some special keys in the storage tree for use by the system, such as ones starting with "_" or "__". In the future we could use this to allow developers to specify finer grained atomic units.

We would also want to use rate limiting to prevent extension developers from accidentally overwhelming the sync service. We already have code for this that was written for the bookmarks API.
Comment 23 by aa@chromium.org, Nov 18, 2010
Labels: -Pri-2 Pri-1
We should do this. :-)
Comment 24 by erikkay@chromium.org, Nov 18, 2010
Yes.  sync is really coming together now and this seems like one of the few missing pieces in the puzzle.

Overall I like your proposal.  I'm curious what the sync team thinks about syncing a general storage tree, but I have a feeling that it can be made to work.

One nice thing about doing it via a generic chrome.extensions.settings is that it also gives the possibility of integration with enterprise policy settings which is another open feature request somewhere.

Comment 25 by cgug...@gmail.com, Nov 18, 2010
I think #22 is an excellent idea, but we must entertain the possibility that some users will not want their extension settings to sync on a per-extension basis to have unique settings for some extensions, but not others. One example I can think of is the 'Email this page (by Google)' extension. A user may want this to open Outlook at work, but Gmail at home, and would have to break syncing of the settings for this extension to have that.
Comment 26 by admwig...@gmail.com, Nov 18, 2010
Well, the UI for setting up Sync already has checkboxes for each of the features supported, so what about just listing each extension that uses this chrome.extensions.settings structure automatically listed there, too?  That way, most users can select Sync Everything, or can select each individually.  At that point, though, a Select All / Select None option would be nice, to make it easy to check them all and then uncheck one or two.  :)
Comment 27 by aa@chromium.org, Nov 18, 2010
#25: That's a good point. We could add a per-extension setting in chrome://extensions/ for whether to sync settings. We might have to wait for the new UI (bug 52447), as it is getting pretty crowded in there.
Comment 28 by fi...@mxd.cz, Dec 17, 2010
#22, #25 = great ideas, as Chrome profile crash is reality and setting everything again and again is a pain...
Issue 68403 has been merged into this issue.
Comment 30 by rico...@gmail.com, Jan 26, 2011
I tkink, that on extensions page (chrome://extensions/), there would be a checkbox called "Sync extension's settings" aside each extension. The checkbox should be defaultly turned ON.
Comment 31 by maxad...@gmail.com, Jan 26, 2011
I agree the above comment: we must have the possibility to disable this kind of sync. An internet Browser without Internet makes no sense, but an internet browser without a Gmail account makes sense.
I have a Gmail account, but but not everybody must have one, and you cannot force all people to have one, because of this sync .... it's enough for me, that I am not able to choose an E-Mail Client, which is not a crappy web based mail client, and I almost forced to use web gmail account.
Comment 32 by torzsmo...@gmail.com, Jan 27, 2011
@maxad...
what makes no sense is your comment.
Google Account != Gmail
and it has nothing to do with this feature request; this is about syncing the extension settings when already syncing other settings.

please try to stay on topic, as more then 120 people get an email every time you make a comment here. thx
Comment 33 by maxad...@gmail.com, Jan 27, 2011
The sense of my comment is that you should avoid to force people using a google account in order to use your browser. Of course, I have gogle account and i would like tovsync everything but therr should be a different option available.
Comment 34 by mr.ber...@gmail.com, Jan 27, 2011
To use this browser, no one is forced to use the (or any other) Sync functionality at all. We are talking about one specific Sync feature here, which is only of importance for those who use Sync already. Yes, I am sure the devs are fully aware that no one should be forced to give its data to Google, but there is absolutely no point in discussing this in this thread.
If you do want more discussion about this topic, I suggest you move to Google's Help Forums.
Comment 35 by annapop@chromium.org, Jan 27, 2011
Issue 70914 has been merged into this issue.
Comment 36 by maxad...@gmail.com, Jan 27, 2011
You are sure that devs arevalready aware of this, but forthe time being i am not able to select a different email client. I would like to use evolution but this browser is not allowing me to do that. I am not sure if devs are aware of these kind of issues. I suggest you to go some basic help forum.
Your conversation has absolutely nothing to do with syncing preferences of extensions.

You can open another issue for your problem.
Comment 38 by bau...@gmail.com, Jan 27, 2011
@maxad: search or create an extension to sync with your account in your server!!and stop your comments unrelated to the subject! dev can access all site/settings/bookmarks...
For my part, I prefer to sync my favorites and setting to Google rather than an unknown site! Internet without Google is like the phone without the yellow pages! and  Chrome without Google...euhhh just use IE

to return to the topic: it should be able to choose extensions / settings to synchronize, merge, or not, by extension individually and not global setting.
Each extension should have a space in sync Google to store settings (perhaps not all setting must be saved).

Comment 39 by fi...@mxd.cz, Jan 27, 2011
it would be also good to mark, when installing, whether the extension is sync capable - so you don't end with half extensions able to sync and half not

may be very annoying with many extensions in use

@maxad - if you want extensions to sync somewhere else, start a new topic
Comment 40 by maxad...@gmail.com, Jan 27, 2011
I am only pointing out thar we shloud be given different options and nobody has ensured this. You say devs are aware. I explained that in other circumstances devs have not been aware. p s.: 
I am not a fan-boy. I am not interested to discuss about IE.
Comment 41 by akalin@chromium.org, Jan 28, 2011
Issue 71132 has been merged into this issue.
#39: Good point. Could make the process much faster if it's determined before syncing which extensions contain information to sync and which don't.

We need an option to choose whether information/settings should be merged or overwritten, too. This would be usefull for example for your own filter lists in adblockers. If you add new filters that make old ones obsolete you wouldn't want to merge but to overwrite them with your new filters.

Summed up:
- Option to (de-)activate sync for every extension, default should be ON. Possibility to activate all/none (user option) (#25, #38)
- Option to mark whether an extension is sync capable or not (dev option) (#39)
- Option to choose if sync should merge or overwrite old information/settings (user option)
Comment 43 by aboush...@gmail.com, Feb 16, 2011
I absolutely agree with the sentiments that have been expressed above. Is there any word on whether the developers agree and are working to make this happen? I also end up setting this up on multiple computers and having to reset extensions settings each time is very time consuming.
Comment 44 by maxcan...@gmail.com, Feb 16, 2011
Here are some questions that need to be answered as definitively as possible before a robust solution can be implemented:

Selective Sync:

- Can developers denote settings that MUST be sync'd?

- Can developers denote settings that CANNOT be sync'd?

- Can users selectively enable/disable synchronizing on a per-extension basis?

- Can users selectively enable/disable synchronizing on a per-SETTING basis?  For example, "For Joe's Proxy Extension, I want every computer to have the same list of proxies (sync proxyList), but I want the default proxy to be different on each computer (don't sync defaultProxy, even though it's sync-able)."

- If users have per-setting selective sync, can developers denote settings that are optionally sync'd (controllable by the user) and settings that are "required" & always sync'd (the user is never given a choice)?

- If users have per-setting selective sync, can developers specify defaults for the optional settings, or do they start as always sync'd, or do they start as always not sync'd?

Merge Conflict Resolution:

Quick definition of a merge conflict: This is what happens whenever 2 browser instances start with the same settings, and then each one is changed *in different ways* between syncs.  Sometimes a delta merge (or "diff merge") is possible--for example, 'SomeProxy' was added on Computer A and 'MyNewProxy' was added on Computer B, so the conflict is resolved by adding 'SomeProxy' to B and 'MyNewProxy' to A.  However, sometimes a delta merge is not possible--for example, if the user creates a proxy with the same name but different information on each computer, or if the user *renames* the same proxy with different names on each computer.

- How often might a merge conflict happen?  Does sync happen often enough that it won't be a frequent issue?

- What happens when an extension is updated and the format of its information changes drastically, then another browser instance (say it is a laptop that hasn't been turned on in a while) tries to sync?

- What diff information is exposed to the browser during a setting sync?  Is it a series of 'ADD'S and 'REMOVE'S so that if the user renames 'MyNewProxy' to 'Questionable Russian Proxy', the browser sees "REMOVE MyNewProxy; ADD Questionable Russian Proxy"?

- Is the diff information generated by Chrome?  Or can developers define their own Diff Strategies?

- Does Chrome provide default Merge Strategies which developers can use for each setting?  For example, "This setting is always clobbered by the newest changes, using the ClobberWithNewest strategy; but this other setting tries to do a delta merge and falls back on clobbering if it fails, using the AttemptDeltaMergeThenClobberWithNewest strategy."

- Can developers define their own Merge Strategies?  What would the inputs and ouputs of a custom merge strategy be?

- If delta merges are attempted, will the results be de-duped for list-based settings?

User Merge Control:

- Are users given any control over how settings are sync'd and merged?

- Can users choose one "master" browser instance that always "wins" conflicts?

- If users can choose a "master" browser instance, is this done on a per-setting basis, a per-extension basis, globally, or according to a plan defined by each developer?  i.e., "This extension is an all-or-nothing sync", "This extension can intelligently sync as long as a 'Master' instance is defined," "This extension has 1 setting that syncs based on the 'Master' instance, but has 1 other setting that requires user input when there are conflicts" and so on.

- Are users notified every time there is a merge conflict, and asked to choose which information "wins"?  If so, can developers define the interface for per-setting conflict resolution, or is there a built-in interface that only requires 'user-friendly' names for the settings to be defined?  For example: "You have a proxy called 'Questionable Russian Anonymous Proxy', but there's already a proxy with the same name on 'MYHOMEBOX'.  Click 'Overwrite MYHOMEBOX' to delete what's on the other computer, 'Sync from MYHOMEBOX' to copy from the other computer, or 'Rename' to change the name of this proxy to avoid confusion."

I think that, the better we answer these questions, the faster this will get implemented, since each one represents something else developers will not have to think about when writing the code.

Also, I feel like it's worth noting that while this is currently working "as designed", syncing should really be considered fundamentally incomplete at best, broken at worst until a solution is in place.  By any reasonable measure, certain extensions SHOULD sync between browser instances, and when they don't, it creates user confusion, dissonance and inconvenience.

Comment 45 by lara...@gmail.com, Feb 16, 2011
The very fact that extensions don't sync settings amongst different computers goes against the theory that all of "Chrome's personal data is kept in the cloud".
Comment 46 by aa@chromium.org, Feb 16, 2011
We're aware this is an important feature and are keen to implement it. There are only so many developer hours, and we haven't gotten to it yet. We've not forgotten about it though.

Please refrain from adding 'me too!' comments. It creates noise and makes the bug harder to read. If you would like to indicate interest in this bug, you can 'star' it and you'll be emailed updates on it.
can this bug get changed so people who starred this bug get e-mailed only when chrome team members update/comment this bug? Thanks
Comment 48 by aa@chromium.org, Feb 16, 2011
Labels: Restrict-AddIssueComment-Commit
Comment 49 by rahulrc@chromium.org, May 13, 2011
Labels: -mstone-x
Comment 50 by akalin@chromium.org, May 16, 2011
Issue 82488 has been merged into this issue.
Comment 51 by akalin@chromium.org, May 16, 2011
Summary: Allow extensions/apps to sync their own settings (was: NULL)
Comment 52 by mihaip@chromium.org, May 20, 2011
Cc: kalman@chromium.org
Comment 53 by annapop@chromium.org, May 26, 2011
Issue 83813 has been merged into this issue.
Comment 54 by annapop@chromium.org, May 31, 2011
Issue 84446 has been merged into this issue.
Comment 55 by annapop@chromium.org, May 31, 2011
Issue 84510 has been merged into this issue.
Project Member Comment 56 by bugdroid1@chromium.org, Aug 10, 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=96159

------------------------------------------------------------------------
r96159 | kalman@chromium.org | Wed Aug 10 02:24:20 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/settings/manifest.json?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/settings/test.html?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/resources/renderer_extension_bindings.js?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/settings?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/extensions/extension_popup_controller_unittest.mm?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/samples.json?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_api.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_cached_noop_storage_unittest.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_service.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_storage_cache.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_leveldb_storage.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profiles/profile_impl.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_service.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_storage_unittest.h?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_noop_storage.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_cached_leveldb_storage_unittest.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/extension_api.json?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_noop_storage.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_apitest.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_storage_unittest.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/experimental.settings.html?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_storage.h?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profiles/profile_impl.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_leveldb_storage_unittest.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_storage_cache.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_leveldb_storage.h?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings.h?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/base/testing_profile.h?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_function_dispatcher.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/experimental.html?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/base/testing_profile.cc?r1=96159&r2=96158&pathrev=96159
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings.cc?r1=96159&r2=96158&pathrev=96159
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_settings_api.cc?r1=96159&r2=96158&pathrev=96159

Implement an initial extension settings API.

Some general notes:
 - It's a lot of code for a single review, about 1.5K lines (plus tests, plus those generated docs, = 3.5K).  Apologies.  But it's close to the minimal amount of useful functionality.  I've left some TODOs in the code to fix up soon.
 - No integration-style tests, but I'll start writing those now.  Works from within a browser though.
 - Sync not hooked up yet, of course.
 - Ditto events.
 - Ditto thinking about incognito mode.
 - Ditto fun bugs like what happens if you set key "foo.bar" to "baz".
 - This is the first significant amount of C++ code I've ever written... so don't hold back.
 - The docs (i.e. my changes to extension_api.json) are a little incomplete, and I'm aware of that.

A summary of the implementation:
 - There is an ExtensionSettings factory-type object which hands out ExtensionSettingsStorage areas for extensions.  You may notice that I basically did the same thing that ExtensionPreferences does (so, lives with the profile, etc).
 - ExtensionSettingsStorage is a pure interface, with three implementations.
   - the main leveldb implementation.
   - a caching decorator, designed to sit on top of the leveldb implementation.
   - a "no-op" implementation which gives a trivial in-memory storage area when wrapped with a cache.  This is used in the cases where the leveldb database fails to initialise (ExtensionSettings handles this).
   -  and note that my plan is, when hooking up sync, that this will be implemented as another decorator.
 - ... the code is pretty well documented so not much else to say.

For testing, turns out gtest is pretty snazzy.  There are a bunch of test fixtrues in extension_settings_storage_unittest.h, so that 3 different configurations are tested: leveldb, leveldb + cache, and no-op + cache.

BUG= 47327 
TEST=unit tests provided


Review URL: http://codereview.chromium.org/7189029
------------------------------------------------------------------------
Comment 57 by rahulrc@chromium.org, Aug 10, 2011
Cc: -kalman@chromium.org
Labels: -SyncEverything
Owner: kalman@chromium.org
Ben - I think this belongs to you? :-)  Please unassign if this isn't the case.
Comment 58 by bolms@chromium.org, Aug 15, 2011
Blocking: 30224
Issue 94226 has been merged into this issue.
Comment 60 by yoz@chromium.org, Sep 21, 2011
Issue 97469 has been merged into this issue.
Comment 61 by annapop@chromium.org, Nov 19, 2011
Issue 104799 has been merged into this issue.
Labels: Mstone-18
Ben, should this be associated with a meta bug?
Comment 63 by aa@chromium.org, Dec 7, 2011
Blocking: 92589
Comment 64 by aa@chromium.org, Dec 7, 2011
Status: Fixed
This is already implemented and available in experimental. (woo)
Comment 65 by aa@chromium.org, Dec 8, 2011
Cc: kalman@chromium.org
Issue 30224 has been merged into this issue.
Comment 66 by annapop@chromium.org, Jul 25, 2012
Issue 138339 has been merged into this issue.
Comment 67 by akalin@chromium.org, Jul 25, 2012
Issue 138339 has been merged into this issue.
Project Member Comment 68 by bugdroid1@chromium.org, Mar 10, 2013
Blocking: -chromium:30224 -chromium:92589 chromium:30224 chromium:92589
Labels: -Area-Internals -Feature-Sync -Feature-Extensions -Mstone-18 Cr-Platform-Extensions Cr-Services-Sync M-18 Cr-Internals
Project Member Comment 69 by bugdroid1@chromium.org, Mar 13, 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment