New issue
Advanced search Search tips

Issue 816736 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Document common patterns for exposing services / interfaces

Project Member Reported by dcheng@chromium.org, Feb 27 2018

Issue description

There's a couple different ways to register an interface today. It'd probably be useful to write down the common patterns somewhere (e.g. frame-associated browser interface exposed to renderer, render-process associated browser interface exposed to renderer, et cetera), as well as pointing at some common helpers (content::BindInterface, content::BindInterfaceInGpuProcess, et cetera) and perhaps some pitfalls (while poking around for info, I found a RFH AddInterface() call which supplies the IO thread task runner but also uses RenderFrameHost, which is likely unsafe).

It would also be useful to document best practices for extending the standard set of exposed interfaces: one way I've seen is to create a WebContentsObserver with a BinderRegistry that listens for OnInterfaceRequestFromFrame and forwards it to BinderRegistry::TryBindInterface.

Along these lines, it might also be useful to document more about services: there are in-process services, but there are different kinds as well (per-profile, global). There are also bona-fide services that live in //services, as well as special service_manager capabilities that control how services are launched/potentially shared/et cetera as well as the concept of 'users': documenting those would also be useful.

(There are probably other things, but I think these are probably some of the most common questions.)
 

Sign in to add a comment