Experimental bookmark model based on tags.

chrome/chrome_browser.gypi

Index: chrome/chrome_browser.gypi
diff --git a/chrome/chrome_browser.gypi b/chrome/chrome_browser.gypi
index 4eec3fbe6f87645ed670aa50968c06f99a7d3a1f..87cf330a3dade44c033a146aee736381f5cf2841 100644
--- a/chrome/chrome_browser.gypi
+++ b/chrome/chrome_browser.gypi
@@ -292,6 +292,9 @@
         'browser/bookmarks/bookmark_storage.h',
         'browser/bookmarks/bookmark_title_match.cc',
         'browser/bookmarks/bookmark_title_match.h',
+        'browser/bookmarks/bookmark_tag_model.cc',

[Yaron, 2013/10/11 10:50:41]

Condition this on the |enabled_enhanced_bookmarks| gyp variable to avoid
overhead. Actually, I see that it's never constructed. What's your plan there?
Will the existing BookmarkModel factory conditionally construct this? Does it
wrap the BookmarkModel and cause it to be loaded?

[noyau (Ping after 24h), 2013/10/11 12:09:21]

Well, it's compiled but removed at link time as nobody uses it yet. Conditioning
it on the |enabled_enhanced_bookmarks| will mean that this could be easily
broken by a change to BookmarkManager, and that the unit tests will not be run
by the bots.
I was thinking that for now the UI will simply create one of those as needed,
passing the BookmarkModel from the factory. We could always make a new factory
later to manage a singleton.

+        'browser/bookmarks/bookmark_tag_model.h',
+        'browser/bookmarks/bookmark_tag_model_observer.h',
         'browser/bookmarks/bookmark_utils.cc',
         'browser/bookmarks/bookmark_utils.h',
         'browser/browser_about_handler.cc',