[Experimental] Fool around with exposing extension bindings via blink

extensions/common/api/mojo/developer_private.mojom

+// Copyright 2016 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.
+
+module extensions.mojom;
+
+struct UpdateExtensionConfigurationParams {
+  string extension_id;
+  bool has_file_access;

[Ken Rockot(use gerrit already), 2016/06/20 17:19:24]

Another possible pattern here would be to define constants for flags like:

struct UpdateExtensionConfigurationParams {
  const uint16 kFlagFileAccess = 1;
  const uint16 kFlagIncognitoAccess = 2;
  const uint16 kFlagErrorCollection = 4;
  // ...

  string extension_id;
  uint16 flags_update_mask;
  uint16 flags;
};

Your call on what you'd prefer. In this case my main hesitation about
"foo"/"has_foo" is that the flags themselves deal with capabilities, so
"has_foo" sounds like it could be referring to the capability "foo" rather than
the presence of the capability flag "foo".

+  bool file_access;
+  bool has_incognito_access;
+  bool incognito_access;
+  bool has_error_collection;
+  bool error_collection;
+  bool has_run_on_all_urls;
+  bool run_on_all_urls;
+  bool has_show_action_button;
+  bool show_action_button;
+};
+
+interface DeveloperPrivate {

[Devlin, 2016/06/18 01:24:59]

Ideally, this interface (and corresponding structs) would be generated.

[Ken Rockot(use gerrit already), 2016/06/20 17:19:25]

Generated from what, the IDL? I don't think we really want there to be a 1:1
correspondence between component mojo interfaces and extension APIs which
consume them. We started down that road when first looking at extensions-on-mojo
and it didn't end up making much sense in practice.

In general, interfaces needed to implement extension APIs should be useful
beyond the scope of only the extensions platform. There may be exceptions to
that rule but I'd expect them to be few in number.

This API of course seems like an exception since it's explicitly dealing with
extensions features, but it's unclear to me that it'd be worth generating mojom
from IDL just for the few cases like this.


Also, the name seems pretty confusing for a mojo interface. I don't think it
always needs to match an extension API name, and in this case I don't think it
should. What about something like:

interface Configuration {
  Update(bool from_user_gesture, ConfigurationUpdateParams params) => ();
};

Note, I dropped Extension from names because this already lives in
extensions::mojom. WDYT?

[Devlin, 2016/06/20 17:49:23]

I think there's multiple scopes here.  What I'm mostly worried about in the
short-term is a "simple" conversion to mojo and blink bindings, which should
still be a *huge* win in terms of security and performance.  I agree that, in
the long run, we should rearchitect the whole system and make interfaces that
are consumable for multiple uses, at which point maybe this pattern becomes less
useful (or we just implement one in terms of the other).  But that's a project
that a) is being worked on by other teams and b) is related but not entirely
parallel to this one.

Note also that no matter what we do, it may well be that we always need an
endpoint for extensions because we need to do all the permissions
checks/bookkeeping/etc (which can't be done in the renderer for security
reasons).  So we could never just say in the renderer:
BlinkTabsCreate() {
  TabsService::Create();
}
There would always have to be an intermediary step there.  So I think more
likely (and compatible with this step) would be:
BlinkTabsCreate() {
  TabsApi::Create();
}

TabsApi::Create() {
  <check stuff>
  TabService::Create();
}

+  UpdateExtensionConfiguration(
+      bool is_user_gesture,
+      UpdateExtensionConfigurationParams params) => ();
+};