NPAPI:AsyncURLValues: Difference between revisions

NPAPI:AsyncURLValues (view source)

Revision as of 04:53, 4 September 2012

475 bytes added , 4 September 2012

→‎Current Proposal

Josh

Confirmed users, Bureaucrats and Sysops emeriti

1,680

edits

@@ Line 14: / Line 14: @@
 = Current Proposal =
-The following NPAPI functions will be added:
+The following NPAPI definitions will be added:
+  typedef enum {
+    NPNAsyncURLVProxy = 1
+  } NPNAsyncURLVariable;
    NPN_AsyncGetValueForURL(NPP npp, NPNAsyncURLVariable variable, const char *url);
-   NPP_AsyncReceiveValueForURL(char *value, uint32_t *len);
+   NPP_AsyncReceiveValueForURL(char *value, uint32_t len);
-The API will use a new variable type in order to be clear about what values should be called via the async API. Supporting the synchronous API variables via the async API would not make it clear which variables browsers might require to be called via the async API.
+Every successful request (returning <code>NPERR_NO_ERROR</code>) should result in a single availability callback, with a NULL value 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. Mozilla would like it to be clear that this is recommended and supported, because 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 use in certain calls.
+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 =
 * None