Pepper Flash settings integration: implement "deauthorize content licenses".

Pepper Flash settings integration: implement "deauthorize content licenses".

A few notes about PepperFlashSettingsManager:
- It doesn't re-establish a channel for each request. It might seem unnecessary at this point. But that is needed for implementing content settings (camera/mic and peer networking), which requires more interactions with the broker process. 
- Similarly, the support of multiple in-flight requests isn't very useful for deauthorizing content licenses, but that is useful for content settings, e.g., sending multiple GetPermissionSettings requests for different setting types.  

BUG=112190
TEST=None

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=139210

[yzshen1, 2012-05-16 21:40:53]

Hi, Brett.

Would you please take a look? Thanks!

A few notes:
- The IDL file contains all operations that I am planning to add for managing
Pepper Flash settings in M21, not just deauthorizing content licenses.

- PepperFlashSettingsManager doesn't re-establish a channel for each request
(which is different from PluginDataRemoverImpl). It might seem unnecessary at
this point. But that is needed for implementing content settings (camera/mic and
peer networking), which requires more interactions with the broker process.

[brettw, 2012-05-17 04:53:54]

I don't quite follow why you maintain multiple in-flight clear requests. Can you
add some background on the necessity for that somewhere (could be in the CL
description).

http://codereview.chromium.org/10391173/diff/1/ppapi/api/private/ppp_flash_br...
File ppapi/api/private/ppp_flash_browser_operations.idl (right):

http://codereview.chromium.org/10391173/diff/1/ppapi/api/private/ppp_flash_br...
ppapi/api/private/ppp_flash_browser_operations.idl:133: * @param[in] sites The
site-specific settings. If a site is sepcified with
sepcified - > specified

[yzshen1, 2012-05-17 07:31:26]

Thanks, Brett!

> I don't quite follow why you maintain multiple in-flight clear requests. Can
you
> add some background on the necessity for that somewhere (could be in the CL
> description).

I have updated the CL description. Supporting multiple in-flight requests is
useful for other features that I am going to add. Therefore, I also did that for
deauthorizing content licenses to make the interface more consistent.

http://codereview.chromium.org/10391173/diff/1/ppapi/api/private/ppp_flash_br...
File ppapi/api/private/ppp_flash_browser_operations.idl (right):

http://codereview.chromium.org/10391173/diff/1/ppapi/api/private/ppp_flash_br...
ppapi/api/private/ppp_flash_browser_operations.idl:133: * @param[in] sites The
site-specific settings. If a site is sepcified with
On 2012/05/17 04:53:54, brettw wrote:
> sepcified - > specified

Done.

[brettw, 2012-05-18 05:32:09]

lgtm

[jam, 2012-05-30 01:41:39]

is there no way to do this change in a different way? the flash stuff doesn't
belong in content/public/browser. i.e. can chrome code inject its own interface
in some src/ppapi file?

[yzshen1, 2012-05-30 07:14:11]

On 2012/05/30 01:41:39, John Abd-El-Malek wrote:
> is there no way to do this change in a different way? the flash stuff doesn't
> belong in content/public/browser. i.e. can chrome code inject its own
interface
> in some src/ppapi file?

I would be very happy to make it right. (And sorry for messing up things.)

I am not quite sure I understand "chrome code inject its own interface in some
src/ppapi file". Would you please talk more about it? (Or I could stop by your
desk if that would save you some time.)

The following are the reasons why I did it this way: (may be wrong)
1) the ability to start/connect to a ppapi broker process lives in content/.
2) now that we are integrating Pepper Flash settings into chrome://settings, the
logic to manipulate Pepper Flash settings (or at least part of it) should live
in chrome/browser/.
3) in order to manipulate Pepper Flash settings, we have to start/connect to a
Flash broker process.
4) considering (1) (2) and (3), we need to expose some kind of interface in
content/public.

Thanks for your help! :)

[yzshen1, 2012-05-30 07:18:49]

One more thing:
Does it look better if I expose a generic API to connect to a ppapi broker
process (in content/public/browser/plugin_service.h)?

On 2012/05/30 07:14:11, yzshen1 wrote:
> On 2012/05/30 01:41:39, John Abd-El-Malek wrote:
> > is there no way to do this change in a different way? the flash stuff
doesn't
> > belong in content/public/browser. i.e. can chrome code inject its own
> interface
> > in some src/ppapi file?
> 
> I would be very happy to make it right. (And sorry for messing up things.)
> 
> I am not quite sure I understand "chrome code inject its own interface in some
> src/ppapi file". Would you please talk more about it? (Or I could stop by your
> desk if that would save you some time.)
> 
> The following are the reasons why I did it this way: (may be wrong)
> 1) the ability to start/connect to a ppapi broker process lives in content/.
> 2) now that we are integrating Pepper Flash settings into chrome://settings,
the
> logic to manipulate Pepper Flash settings (or at least part of it) should live
> in chrome/browser/.
> 3) in order to manipulate Pepper Flash settings, we have to start/connect to a
> Flash broker process.
> 4) considering (1) (2) and (3), we need to expose some kind of interface in
> content/public.
> 
> Thanks for your help! :)