NPAPI:AsyncURLValues: Difference between revisions
(Created page with "= Status = Under consideration. = Contributors = * Last modified: September 9, 2011 * Authors: Josh Aas (Mozilla Corporation) = Problem Summary = Some values provided via th...") |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
= Contributors = | = Contributors = | ||
* Last modified: September | * Last modified: September 13, 2012 | ||
* Authors: Josh Aas (Mozilla Corporation) | * Authors: Josh Aas (Mozilla Corporation) | ||
| Line 14: | Line 14: | ||
= Current Proposal = | = Current Proposal = | ||
The following NPAPI | The following NPAPI definitions will be added: | ||
NPN_AsyncGetValueForURL(NPP | typedef enum { | ||
NPP_AsyncReceiveValueForURL(char *value, uint32_t | NPNAsyncURLVProxy = 1 | ||
} NPNAsyncURLVariable; | |||
NPError NPN_AsyncGetValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url); | |||
void NPP_AsyncReceiveValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url, char *value, uint32_t len); | |||
The | Every successful request (returning <code>NPERR_NO_ERROR</code>) should result in a single availability callback, with <code>value == NULL</code> if there was a problem coming up with a value. The callback can be nested (immediate, occurring prior to the return of the request call to <code>NPN_AsyncGetValueForURL</code>). | ||
For example - Mozilla plans to require that proxy information be requested via the async API. | The plugin would be responsible for freeing any callback result via NPN_MemFree. | ||
The API will use a new async variable type in order to be clear about what values can/should be requested via the async API. Supporting the synchronous API variables via the async API would not make this clear. For example - Mozilla plans to require that proxy information be requested via the async API. A synchronous request would result in failure. Under this proposal, Mozilla can simply deprecate usage of <code>NPNURLVProxy</code> entirely, instead of insisting that it only be used in certain contexts. | |||
This proposal does not cover non-URL-based values (<code>NPN_GetValue</code>) because we have not discovered a need for such an extension yet. | |||
= Open Issues = | = Open Issues = | ||
* None | * None | ||
Latest revision as of 12:05, 13 September 2012
Status
Under consideration.
Contributors
- Last modified: September 13, 2012
- Authors: Josh Aas (Mozilla Corporation)
Problem Summary
Some values provided via the NPN_GetValueForURL API can result in main-thread i/o (notably: NPNURLVProxy). The purpose of this proposal is to allow for asynchronous retrieval of values.
Current Proposal
The following NPAPI definitions will be added:
typedef enum {
NPNAsyncURLVProxy = 1
} NPNAsyncURLVariable;
NPError NPN_AsyncGetValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url);
void NPP_AsyncReceiveValueForURL(NPP instance, NPNAsyncURLVariable variable, const char *url, char *value, uint32_t len);
Every successful request (returning NPERR_NO_ERROR) should result in a single availability callback, with value == NULL if there was a problem coming up with a value. The callback can be nested (immediate, occurring prior to the return of the request call to NPN_AsyncGetValueForURL).
The plugin would be responsible for freeing any callback result via NPN_MemFree.
The API will use a new async variable type in order to be clear about what values can/should be requested via the async API. Supporting the synchronous API variables via the async API would not make this clear. For example - Mozilla plans to require that proxy information be requested via the async API. A synchronous request would result in failure. Under this proposal, Mozilla can simply deprecate usage of NPNURLVProxy entirely, instead of insisting that it only be used in certain contexts.
This proposal does not cover non-URL-based values (NPN_GetValue) because we have not discovered a need for such an extension yet.
Open Issues
- None