Moving prepopulated search engines to a JSON file.

chrome/browser/search_engines/prepopulated_engines_schema.json

Index: chrome/browser/search_engines/prepopulated_engines_schema.json
diff --git a/chrome/browser/search_engines/prepopulated_engines_schema.json b/chrome/browser/search_engines/prepopulated_engines_schema.json
new file mode 100644
index 0000000000000000000000000000000000000000..f8d6a6a50062517ec531d974db3c3471ccb559cd
--- /dev/null
+++ b/chrome/browser/search_engines/prepopulated_engines_schema.json
@@ -0,0 +1,57 @@
+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This file is used by json_to_struct.py to generate prepopulated_engine.h/cc.
+// Any time you modify this file regenerate the .h/.cc. See
+// prepopulated_engines.json for details.
+
+{
+  "type_name": "PrepopulatedEngine",
+  "headers": [
+    "chrome/browser/search_engines/search_engine_type.h"
+  ],
+  "schema": [
+    { "field": "name", "type": "string16" },

[not at google - send to devlin, 2012/11/12 18:38:13]

Have you considered using JSON schema for this? Changing this to use it would be
a bit of make-work but it'd be consistent with the other place we do JSON based
code generation in chromium (at least, the places I am aware of).

We have a parsing library in tools/json_schema_compiler/model.py. This file
basically maps onto JSON schema: type_name is namespace. ctype is compiled_type
(our own thing). Etc.

There is no equivalent of "headers" but you could pull it out separately, or
consider making it part of the gyp generation.

[beaudoin, 2012/11/13 18:44:26]

I considered it but decided against it because of the large overhead it would
have imposed in my code, and because my schemas only allow for C fundamental
data types whereas the json_schema_compiler allows std::string and more. For
simplicity, I would argue the proposed approach is better.

[not at google - send to devlin, 2012/11/13 20:28:07]

I don't know about large overhead? It's just a matter of reusing model.py. That
doesn't really have any knowledge of C++ so you're free to use string16 rather
than std::string or whatever.

Anyway, I guess I don't really feel strongly. I'd argue (as I did before) that
it's nice to not reinvent a JSON meta-language and use JSON Schema, which we
already have tools built around, but happy to go with your judgement here.

[not at google - send to devlin, 2012/11/13 20:34:56]

Wild speculative thought: another option would be to augment JSON schema
compiler (as the IDL work did) to add the generators that you need.

+    { "field": "keyword", "type": "string16" },
+    // If omitted, there is no favicon.

[Peter Kasting, 2012/11/12 22:46:36]

Do any of our engines not have a favicon?  If not let's omit this comment so
this doesn't appear to be optional.

If we don't already, we probably could/should make the code generator check that
every engine definition contains all the non-optional fields.

[beaudoin, 2012/11/13 18:44:26]

Most engines in the "UMA-only engines" do not define a favicon.
I've added a way to define optional fields and an explicit check.

[Peter Kasting, 2012/11/13 19:23:10]

Hmmm.  I'm torn between making them define favicons too (it wouldn't be hard) so
that we can require this, or leaving things as they are and adding a comment
saying that if you're not declaring an UMA-only engine you need to have this. 
The former is more work for data we're not going to use anyway, but safer. 
WDYT?

[beaudoin, 2012/11/13 21:42:03]

Added the missing favicons and made it mandatory. One of the UMA-only already
had a favicon, so I think it makes sense, and it reduces the risk of future
errors...

Done.

+    { "field": "favicon_url", "type": "string" },
+    { "field": "search_url", "type": "string" },
+    { "field": "encoding", "type": "string", "default": "UTF-8" },
+    // If omitted, this engine does not support suggestions.
+    { "field": "suggest_url", "type": "string" },
+    // If omitted, this engine does not support instant.
+    { "field": "instant_url", "type": "string" },
+    // A list of URL patterns that can be used, in addition to |search_url|,
+    // to extract search terms from a URL.
+    {
+      "field": "alternate_urls",
+      "type": "array",
+      "contents": { "type": "string" }
+    },
+    {
+      "field": "type",
+      "type": "enum",
+      "ctype": "SearchEngineType",
+      "default": "SEARCH_ENGINE_OTHER"
+    },
+    // Unique id for this prepopulate engine (corresponds to
+    // TemplateURL::prepopulate_id). This ID must be greater than zero and must
+    // remain the same for a particular site regardless of how the url changes;
+    // the ID is used when modifying engine data in subsequent versions, so that
+    // we can find the "old" entry to update even when the name or URL changes.
+    //
+    // This ID must be "unique" within one country's prepopulated data, but two
+    // entries can share an ID if they represent the "same" engine (e.g. Yahoo!
+    // US vs. Yahoo! UK) and will not appear in the same user-visible data set.
+    // This facilitates changes like adding more specific per-country data in
+    // the future; in such a case the localized engines will transparently
+    // replace the previous, non-localized versions.  For engines where we need
+    // two instances to appear for one country (e.g. Bing Search U.S. English
+    // and Spanish), we must use two different unique IDs (and different
+    // keywords).
+    //
+    // See prepopulated_engines.json for the list of available IDs.
+    { "field": "id", "type": "int" }
+  ]
+}