Implementation of the "Redirect URLs to Packaged Apps" feature.

chrome/browser/extensions/api/url_handlers/url_handlers_api.cc

Index: chrome/browser/extensions/api/url_handlers/url_handlers_api.cc
diff --git a/chrome/browser/extensions/api/url_handlers/url_handlers_api.cc b/chrome/browser/extensions/api/url_handlers/url_handlers_api.cc
new file mode 100644
index 0000000000000000000000000000000000000000..ba06db17864449a79c75977f7dc87b39f2b2db6b
--- /dev/null
+++ b/chrome/browser/extensions/api/url_handlers/url_handlers_api.cc
@@ -0,0 +1,26 @@
+// 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.
+

[not at google - send to devlin, 2013/08/19 23:32:24]

These should be in chrome/common/extensions/manifest_handlers/...

[sergeygs, 2013/08/29 08:24:42]

Did you mean:
a) chrome/common/extensions/api/url_handlers/, or
b) chrome/common/extensions/manifest_url_handler.*

? 

I suspect the latter, but in any case, could you explain why these should be
there? The new manifest key is a part of an API, so
chrome/browser/extensions/api seems like a logical place for its parser. FWIW, I
was mimicking the implementation of the file_handlers API, and the respective
files from there are under in the same places I put mine. Also,
manifest_url_handler.* deals almost exclusively with extension-specific keys:
the only exception is 'update_url', which is still shared between both
extensions and apps. The new url_handlers key will be purely app-specific.

Does that sound convincing enough? If not, I propose to leave this as is for
now, and at a later time refactor both url_handlers and file_handlers as you've
suggested, so they still look similar.

On 2013/08/19 23:32:24, kalman wrote:

[not at google - send to devlin, 2013/08/29 17:35:56]

URL handles don't really have an API associated with them, do they? Like there
is no chrome.urlHandler.someMethod(). The code in api/ should have been
restricted to such implementations (i.e. things that appear in
_api_features.json) though we haven't stuck with this precedent, as you've
noticed with file handlers.

Up to you though. i would like for both this and file handlers to end up in
chrome/common/extensions/manifest_handlers/{file,url}_handler... and if you want
to move it later, along with file handlers... sure. It's just more work and a
more daunting diff later. IMO it would be easier to move now.

[sergeygs, 2013/08/30 00:39:44]

Not entirely sure how API is defined for this case, but perhaps they do have an
API: they trigger one flavor of chrome.app.runtime.onLaunched to be sent to the
app. Does that count as an API here? Things in
chrome/common/extensions/manifest_url_handler.* are basically just dumb URLs. 

For now I'd value code uniformity higher than prior conventions that have
already been broken. I've filed b/281754 for this: let's discuss offline.

[not at google - send to devlin, 2013/08/30 17:07:58]

Let's just figure it out on that bug.

Things in

+#include "chrome/browser/extensions/api/url_handlers/url_handlers_api.h"
+
+#include "base/lazy_instance.h"
+#include "chrome/common/extensions/api/url_handlers/url_handlers_parser.h"
+
+namespace extensions {
+
+UrlHandlersAPI::UrlHandlersAPI(Profile* profile) {
+  (new UrlHandlersParser)->Register();
+}
+
+UrlHandlersAPI::~UrlHandlersAPI() {
+}
+
+static base::LazyInstance<ProfileKeyedAPIFactory<UrlHandlersAPI> >
+    g_factory = LAZY_INSTANCE_INITIALIZER;
+
+ProfileKeyedAPIFactory<UrlHandlersAPI>* UrlHandlersAPI::GetFactoryInstance() {
+  return &g_factory.Get();
+}
+
+}  // namespace extensions