NPAPI:ClearSiteData: Difference between revisions

NPAPI:ClearSiteData (view source)

Revision as of 00:28, 24 December 2010

118 bytes removed , 24 December 2010

no edit summary

Josh

Confirmed users, Bureaucrats and Sysops emeriti

1,680

edits

@@ Line 5: / Line 5: @@
 = Contributors =
-* Last modified: December 20, 2010
+* Last modified: December 23, 2010
 * Authors: Julian Reschke (greenbytes), Dan Witte (Mozilla), Bernhard Bauer (Chromium), Rajesh Gwalani (Adobe), Josh Aas (Mozilla)
@@ Line 52: / Line 52: @@
 #define NPERR_MALFORMED_ORIGIN (NPERR_BASE + 16)
 </pre>
+For any other type of error the plugin should return <code>NPERR_GENERIC_ERROR</code>.
 If site data is in use by an instance of the plugin when <code>NPP_ClearSiteData</code> is called then it is up to the plugin to do the right thing.
@@ Line 57: / Line 59: @@
 = Open Issues  =
+* Make sure the requirements for parsing the origin argument are not too much of a burden for plugin developers.
 * Do we need a method for discovering what site data the plugin has? Mozilla and Apple have expressed a strong desire for this.
 * What is the syntax for an IPv6 address in site? As per RFC 3986 "IP-literal" ([http://greenbytes.de/tech/webdav/rfc3986.html#host.ip])?
-* What should be returned if a plugin does not support a requested type of data. What if it does not exist? What if clearing that data is not possible or simply not supported for any reason (data remains)?
-* Make sure the requirements for parsing the origin argument are not too much of a burden for plugin developers.
 * Suggested that we document what happens when a particular plug-in is keyed by domain, not origin.  This way for simplicity purposes the API can handle both models, regardless of how it's keyed.  The specific suggestion is that for a plug-in that stores domain-keyed info, that plug-in will just strip the protocol and (optional) port.