ppapi/api/pp_errors.idl - Issue 270213004: Implement Pepper PPB_VideoDecoder interface.

Side by Side Diff: ppapi/api/pp_errors.idl

Issue 270213004: Implement Pepper PPB_VideoDecoder interface. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Rebase, update to PPAPI message map macros. Created 6 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:

View unified diff | Download patch | Annotate | Revision Log

« content/renderer/pepper/pepper_video_decoder_host.cc ('K') | « mojo/examples/pepper_container_app/resource_creation_impl.cc ('k') | ppapi/c/pp_errors.h » ('j') | ppapi/examples/video_decode/video_decode.cc » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.	1 /* Copyright (c) 2012 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	5

6 /**	6 /**

7 * This file defines an enumeration of all PPAPI error codes.	7 * This file defines an enumeration of all PPAPI error codes.

8 */	8 */

9	9

10 /**	10 /**

(...skipping 160 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
171 * in use.	171 * in use.

172 */	172 */

173 PP_ERROR_ADDRESS_IN_USE = -108,	173 PP_ERROR_ADDRESS_IN_USE = -108,

174 /**	174 /**

175 * This value indicates that the message was too large for the transport.	175 * This value indicates that the message was too large for the transport.

176 */	176 */

177 PP_ERROR_MESSAGE_TOO_BIG = -109,	177 PP_ERROR_MESSAGE_TOO_BIG = -109,

178 /**	178 /**

179 * This value indicates that the host name could not be resolved.	179 * This value indicates that the host name could not be resolved.

180 */	180 */

181 PP_ERROR_NAME_NOT_RESOLVED = -110	181 PP_ERROR_NAME_NOT_RESOLVED = -110,

	182 /**

	183 * This value indicates that plugin passed bad input data to the browser.
	yzshen1 2014/05/14 18:08:23 - Does it make sense to consider reusing existing - Does it make sense to consider reusing existing errors? * PP_ERROR_UNREADABLE_INPUT -> PP_ERROR_BADARGUMENT * PP_ERROR_PLATFORM_FAILED -> PP_ERROR_NOTSUPPORTED or simply PP_ERROR_FAILED. (But I am not sure what "platform failure" actually means.) - If we decide to add these two, maybe we could consider changing the values, say, putting them in the range of -14 ~ -19. -100~-110 are networking errors and I think we probably want to reserve some more values starting from -111 for future networking errors. bbudge 2014/05/14 19:35:04 I thought about both of those possibilities. PP_ER Show quoted text On 2014/05/14 18:08:23, yzshen1 (OOO until may 19) wrote: > - Does it make sense to consider reusing existing errors? > * PP_ERROR_UNREADABLE_INPUT -> PP_ERROR_BADARGUMENT > * PP_ERROR_PLATFORM_FAILED -> PP_ERROR_NOTSUPPORTED or simply PP_ERROR_FAILED. > (But I am not sure what "platform failure" actually means.) > > - If we decide to add these two, maybe we could consider changing the values, > say, putting them in the range of -14 ~ -19. -100~-110 are networking errors and > I think we probably want to reserve some more values starting from -111 for > future networking errors. I thought about both of those possibilities. PP_ERROR_BADARGUMENT to me means something was NULL or out of range and doesn't express that a buffer of data was malformed. (I'm changing this name to PP_ERROR_MALFORMED_INPUT). PP_ERROR_FAILED is a little too generic to capture that there was a failure in Chrome's implementation, and doesn't express that the failure is unrecoverable. However I feel less strongly about this one. In the next CL I'll move these into the empty range you suggest. yzshen1 2014/05/14 22:58:16 Okay. One thing I don't quite understand is "platf Show quoted text On 2014/05/14 19:35:04, bbudge wrote: > On 2014/05/14 18:08:23, yzshen1 (OOO until may 19) wrote: > > - Does it make sense to consider reusing existing errors? > > * PP_ERROR_UNREADABLE_INPUT -> PP_ERROR_BADARGUMENT > > * PP_ERROR_PLATFORM_FAILED -> PP_ERROR_NOTSUPPORTED or simply > PP_ERROR_FAILED. > > (But I am not sure what "platform failure" actually means.) > > > > - If we decide to add these two, maybe we could consider changing the values, > > say, putting them in the range of -14 ~ -19. -100~-110 are networking errors > and > > I think we probably want to reserve some more values starting from -111 for > > future networking errors. > > I thought about both of those possibilities. PP_ERROR_BADARGUMENT to me means > something was NULL or out of range and doesn't express that a buffer of data was > malformed. (I'm changing this name to PP_ERROR_MALFORMED_INPUT). > > PP_ERROR_FAILED is a little too generic to capture that there was a failure in > Chrome's implementation, and doesn't express that the failure is unrecoverable. > However I feel less strongly about this one. In the next CL I'll move these into > the empty range you suggest. Okay. One thing I don't quite understand is "platform failure". Would you please tell me more about the meaning? (And maybe add that to the comment of the error code)
	184 */

	185 PP_ERROR_UNREADABLE_INPUT = -111,

	186 /**

	187 * This value indicates that a platform failure occurred. This indicates that

	188 * the browser could not complete a valid request from the plugin.

	189 */

	190 PP_ERROR_PLATFORM_FAILED = -112

182 };	191 };

183	192

OLD	NEW