content/common/service_worker/service_worker_provider.mojom - Issue 2653493009: Add two interfaces for ServiceWorkerProviderContext/ProviderHost

Side by Side Diff: content/common/service_worker/service_worker_provider.mojom

Issue 2653493009: Add two interfaces for ServiceWorkerProviderContext/ProviderHost (Closed)

Patch Set: Rebased/Fixed unittests when BrowserSideNavigation is enabled Created 3 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

« content/common/service_worker/service_worker.mojom ('K') | « content/common/service_worker/service_worker.mojom ('k') | content/common/service_worker/service_worker_provider_host_info.h » ('j') | content/common/service_worker/service_worker_provider_host_info.h » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 // Copyright 2017 The Chromium Authors. All rights reserved.	1 // Copyright 2017 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 module content.mojom;	5 module content.mojom;

6	6

	7 import "content/common/service_worker/service_worker_provider_interfaces.mojom";

7 import "content/common/service_worker/service_worker_types.mojom";	8 import "content/common/service_worker/service_worker_types.mojom";

8	9

9 // A container object carried from the renderer to the browser process.	10 // A container object carried from the renderer to the browser process.

10 // This contains the params for the constructor of ServiceWorkerProviderHost.	11 // This contains the params for the constructor of ServiceWorkerProviderHost.
	falken 2017/05/18 04:13:10 content::ServiceWorkerProviderHost content::ServiceWorkerProviderHost shimazu 2017/05/19 08:31:07 Done. Show quoted text On 2017/05/18 04:13:10, falken wrote: > content::ServiceWorkerProviderHost Done.
11 // See also comments in	12 // See also comments in

12 // content/common/service_worker/service_worker_provider_host_info.h.	13 // content/common/service_worker/service_worker_provider_host_info.h.

13 struct ServiceWorkerProviderHostInfo {	14 struct ServiceWorkerProviderHostInfo {

14 int32 provider_id;	15 int32 provider_id;

15 int32 route_id;	16 int32 route_id;

16 ServiceWorkerProviderType type;	17 ServiceWorkerProviderType type;

17 bool is_parent_frame_secure;	18 bool is_parent_frame_secure;

	19 associated ServiceWorkerProviderHost& host_request;

	20 associated ServiceWorkerProvider client_ptr_info;
	falken 2017/05/18 04:13:10 Does it make more sense to just name these \|provid Does it make more sense to just name these \|provider_host\| and \|provider\|? I probably just don't understand Mojo enough but why the nouns "request" and "client pointer info"? shimazu 2017/05/19 08:31:07 I thought _request/_ptr_info are informative becau Show quoted text On 2017/05/18 04:13:10, falken wrote: > Does it make more sense to just name these \|provider_host\| and \|provider\|? I > probably just don't understand Mojo enough but why the nouns "request" and > "client pointer info"? I thought _request/_ptr_info are informative because there are several types related to an interface. For example, these four types are used for ServiceWorkerProviderHost interface: - ServiceWorkerProviderHost - AssociatedRequest<ServiceWorkerProviderHost> - AssociatedBinding<ServiceWorkerProviderHost> - AssociatedInterfacePtrInfo<ServiceWorkerProviderHost> - AssociatedInterfacePtr<ServiceWorkerProviderHost> Request and InterfacePtrInfo are the information to carry the endpoints over mojo connection, and Binding and InterfacePtr are receptacles of these endpoints. What do you think we have _request/_ptr_info for Request and PtrInfo, and no suffix for Binding and InterfacePtr? falken 2017/05/22 08:28:12 OK if this is consistent with a common Mojo naming Show quoted text On 2017/05/19 08:31:07, shimazu wrote: > On 2017/05/18 04:13:10, falken wrote: > > Does it make more sense to just name these \|provider_host\| and \|provider\|? I > > probably just don't understand Mojo enough but why the nouns "request" and > > "client pointer info"? > > I thought _request/_ptr_info are informative because there are several types > related to an interface. For example, these four types are used for > ServiceWorkerProviderHost interface: > > - ServiceWorkerProviderHost > - AssociatedRequest<ServiceWorkerProviderHost> > - AssociatedBinding<ServiceWorkerProviderHost> > - AssociatedInterfacePtrInfo<ServiceWorkerProviderHost> > - AssociatedInterfacePtr<ServiceWorkerProviderHost> > > Request and InterfacePtrInfo are the information to carry the endpoints over > mojo connection, and Binding and InterfacePtr are receptacles of these > endpoints. > > What do you think we have _request/_ptr_info for Request and PtrInfo, and no > suffix for Binding and InterfacePtr? > OK if this is consistent with a common Mojo naming scheme, then I'm OK with it.
18 };	21 };

OLD	NEW