Return void from all PPP CDM API interface methods

Return void from all PPP CDM API interface methods

Since we will support only out of process CDMs, the return values
are not of interest to callers. All the return values conveyed was
that a message was dispatched successfully.

BUG=none
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=156456

[Tom Finegan, 2012-09-11 03:20:19]

Dear reviewers,

PTAL-- hopefully this can land without much iteration, but I'm not certain about
the PluginInstance changes-- should I leave those alone (and revert the change
to ppapi_decryptor)? Maybe we do care to report a failure to even call the
plugin.

Thanks!

[dmichael (off chromium), 2012-09-11 15:59:17]

http://codereview.chromium.org/10928098/diff/1/webkit/plugins/ppapi/ppapi_plu...
File webkit/plugins/ppapi/ppapi_plugin_instance.cc (right):

http://codereview.chromium.org/10928098/diff/1/webkit/plugins/ppapi/ppapi_plu...
webkit/plugins/ppapi/ppapi_plugin_instance.cc:1461: return;
At this level, I think it's up to you guys what you want to return. If you want
to be able to handle these kinds of failures, then returning bool makes sense.
If not, then maybe you should use DCHECKs or NOTREACHED()?

[Tom Finegan, 2012-09-11 16:49:24]

I restored the return values for the PluginInstance methods that provide access
to the PPP CDM API, and reverted the changes to PpapiDecryptor.

http://codereview.chromium.org/10928098/diff/1/webkit/plugins/ppapi/ppapi_plu...
File webkit/plugins/ppapi/ppapi_plugin_instance.cc (right):

http://codereview.chromium.org/10928098/diff/1/webkit/plugins/ppapi/ppapi_plu...
webkit/plugins/ppapi/ppapi_plugin_instance.cc:1461: return;
On 2012/09/11 15:59:17, dmichael wrote:
> At this level, I think it's up to you guys what you want to return. If you
want
> to be able to handle these kinds of failures, then returning bool makes sense.
> If not, then maybe you should use DCHECKs or NOTREACHED()?

Done.

[dmichael (off chromium), 2012-09-12 16:22:33]

lgtm

[ddorwin, 2012-09-12 22:50:54]

LGTM for media code. One question.

http://codereview.chromium.org/10928098/diff/5001/ppapi/cpp/private/content_d...
File ppapi/cpp/private/content_decryptor_private.cc (right):

http://codereview.chromium.org/10928098/diff/5001/ppapi/cpp/private/content_d...
ppapi/cpp/private/content_decryptor_private.cc:32: return;
Now we have a lot of silent failures. I guess they should never occur, but...

Would it be bad to have the C++ functions return bool even though the C
interfaces return void? The C++ functions always execute on one side of the
proxy, right?

[Tom Finegan (google), 2012-09-12 22:58:18]

Syncing, rebasing, and uploading CL again before CQ'ing.

http://codereview.chromium.org/10928098/diff/5001/ppapi/cpp/private/content_d...
File ppapi/cpp/private/content_decryptor_private.cc (right):

http://codereview.chromium.org/10928098/diff/5001/ppapi/cpp/private/content_d...
ppapi/cpp/private/content_decryptor_private.cc:32: return;
On 2012/09/12 22:50:54, ddorwin wrote:
> Now we have a lot of silent failures. I guess they should never occur, but...
> 
> Would it be bad to have the C++ functions return bool even though the C
> interfaces return void? The C++ functions always execute on one side of the
> proxy, right?

They could return errors, but we're already on the plugin side of the proxy when
the C++ function is called. For GenerateKeyRequest, the return value would be
handled in PPP_ContentDecryptor_Private_Proxy::OnMsgGenerateKeyRequest (the
message handler in ppp_content_decryptor_private.cc). Basically, it's already
beyond the point where it's possible to notify PluginInstance of the failure
(outside of sending another message back).

[commit-bot: I haz the power, 2012-09-12 23:09:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10928098/6002

[commit-bot: I haz the power, 2012-09-13 01:36:49]

Change committed as 156456

[xhwang, 2012-09-13 12:24:58]

Thanks for the quick patch! Just a few questions.

http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
File ppapi/cpp/private/content_decryptor_private.cc (right):

http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
ppapi/cpp/private/content_decryptor_private.cc:32: return;
For here and below, if this happens, is it a coding error or runtime error? If
former, change to DCHECK or add NOTREACHED?

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
File webkit/media/crypto/ppapi/cdm_wrapper.cc (right):

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
webkit/media/crypto/ppapi/cdm_wrapper.cc:130: return;
Should we return a keyerror here? Based on the spec, if the key request cannot
be generated, a keyerror should be fired
(http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1b/encrypted-media/encrypted...)

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
webkit/media/crypto/ppapi/cdm_wrapper.cc:168: return;
ditto, a keyerror here?

[Tom Finegan, 2012-09-14 00:08:37]

About the additional work in comments: new CL, or add the work here?

http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
File ppapi/cpp/private/content_decryptor_private.cc (right):

http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
ppapi/cpp/private/content_decryptor_private.cc:32: return;
On 2012/09/13 12:24:59, xhwang wrote:
> For here and below, if this happens, is it a coding error or runtime error? If
> former, change to DCHECK or add NOTREACHED? 

Yeah... I was being a little bit over conservative about changes in this CL.
Getting rid of the if in favor of a PP_DCHECK() seems better.

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
File webkit/media/crypto/ppapi/cdm_wrapper.cc (right):

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
webkit/media/crypto/ppapi/cdm_wrapper.cc:130: return;
On 2012/09/13 12:24:59, xhwang wrote:
> Should we return a keyerror here? Based on the spec, if the key request cannot
> be generated, a keyerror should be fired
>
(http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1b/encrypted-media/encrypted...)

Makes sense. I agree.

http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
webkit/media/crypto/ppapi/cdm_wrapper.cc:168: return;
On 2012/09/13 12:24:59, xhwang wrote:
> ditto, a keyerror here?

Same, agreed.

[xhwang, 2012-09-14 00:18:06]

A new CL with reference to this CL (in description) would work.

On 2012/09/14 00:08:37, tomf wrote:
> About the additional work in comments: new CL, or add the work here?
> 
>
http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
> File ppapi/cpp/private/content_decryptor_private.cc (right):
> 
>
http://codereview.chromium.org/10928098/diff/6002/ppapi/cpp/private/content_d...
> ppapi/cpp/private/content_decryptor_private.cc:32: return;
> On 2012/09/13 12:24:59, xhwang wrote:
> > For here and below, if this happens, is it a coding error or runtime error?
If
> > former, change to DCHECK or add NOTREACHED? 
> 
> Yeah... I was being a little bit over conservative about changes in this CL.
> Getting rid of the if in favor of a PP_DCHECK() seems better.
> 
>
http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
> File webkit/media/crypto/ppapi/cdm_wrapper.cc (right):
> 
>
http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
> webkit/media/crypto/ppapi/cdm_wrapper.cc:130: return;
> On 2012/09/13 12:24:59, xhwang wrote:
> > Should we return a keyerror here? Based on the spec, if the key request
cannot
> > be generated, a keyerror should be fired
> >
>
(http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1b/encrypted-media/encrypted...)
> 
> Makes sense. I agree.
> 
>
http://codereview.chromium.org/10928098/diff/6002/webkit/media/crypto/ppapi/c...
> webkit/media/crypto/ppapi/cdm_wrapper.cc:168: return;
> On 2012/09/13 12:24:59, xhwang wrote:
> > ditto, a keyerror here?
> 
> Same, agreed.

[jvoung (off chromium), 2012-09-16 17:32:56]

Hi did running the IDL "generator.py" not update the "pnacl_shim.c" file?
E.g., in http://codereview.chromium.org/10913291/

[Tom Finegan, 2012-09-17 22:13:51]

On 2012/09/16 17:32:56, jvoung (chromium) wrote:
> Hi did running the IDL "generator.py" not update the "pnacl_shim.c" file?
> E.g., in http://codereview.chromium.org/10913291/

I didn't see a change to pnacl_shim.c-- this could easily have been my fault. I
ran generator.py before rebasing my tree, but not after the rebase. I did this:

1) Wrote CL
2) Got LGTM
3) Rebase
4) CQ'd change

Should I have had another step where I ran generator.py, just in case?

[jvoung (off chromium), 2012-09-17 22:21:16]

On 2012/09/17 22:13:51, tomf wrote:
> On 2012/09/16 17:32:56, jvoung (chromium) wrote:
> > Hi did running the IDL "generator.py" not update the "pnacl_shim.c" file?
> > E.g., in http://codereview.chromium.org/10913291/
> 
> I didn't see a change to pnacl_shim.c-- this could easily have been my fault.
I
> ran generator.py before rebasing my tree, but not after the rebase. I did
this:
> 
> 1) Wrote CL
> 2) Got LGTM
> 3) Rebase
> 4) CQ'd change
> 
> Should I have had another step where I ran generator.py, just in case?

Ah, it might have been that the generator.py change landed after you ran it the
first time.  I think normally you *wouldn't* need to run generator.py an extra
time, so maybe it was just a one-off thing.  Thanks!