A more extensible Pepper plugin interface

Brett Wilson brettw at google.com
Thu Apr 29 08:57:21 PDT 2010


One critical thing that has remained unaddressed with the Pepper
inferfaces is good versioning and extensibility. This desperately
needs to be addressed before it can be deployed.

In spending the last few months trying to shoehorn a bunch of new
stuff into NPAPI, it has come up several times that it might be better
to break backwards compatibility with NPAPI. This is becoming more
glaring as the additions to NPAPI become larger than the subset of
capabilities we plan to keep from the old API, and most recently it
came up in conversations several of us had with some folks at Mozilla.

Other random stuff I've heard various browser and plugin vendors, as
well as individuals like me would like to change that might involve
non-backwards compatible changes:
- Remove some of the 10+ year old cruft that is irrelevant today
- Unify the init sequence so Linux isn't different
- Pass exceptions through NPRuntime
- Improve string ownership in Variant.

The direction we currently favor is going with a string-based naming
for "interfaces," which are basically just named vtables. The plugin
and the browser would each implement a
 void* GetInterface(const char* interface_name)
function for the other to call. "Interfaces" would be a bit like a
class and represent a discrete capability. This makes capability
testing easy for both sides, and means both plugins and browsers can
support various parts of the spec without supporting everything in a
particular point in time.

Examples would be that Mozilla could decide not to implement the
"Device3D" interface if they didn't want to, but could support any
number of other capabilities, even if they were added more recently.
This makes the fallback code in the plugin much easier and less
error-prone than checking version numbers. Likewise, an advanced
plugin may want to participate in "find in page" or support printing
(two things currently in the Pepper header), so would expose those
interfaces to the browser. Most plugins wouldn't care about this, so
wouldn't need to be bothered by these capabilities at all. Apple could
implement a Mac-specific one where the current values for querying the
Mac event model would live, and they wouldn't have to work so hard to
pick "unique" integer values for the enum, just a properly descriptive
string for the interface name.

(I think of this a bit like COM-lite. Rather than individual objects
supporting different interfaces, it's the entire browser or the plugin
supporting the interface rather than particular objects. The API would
keep the basic C-ness it has now and hopefully avoid a lot of the
complexity associated with COM, which I think is overkill for our
needs.)

Interfaces are frozen (after some initial development). If you need to
extend the "ImageData" you can make an "ImageData2" interface with the
additional functions you need (not sure if this would just add extra
functions or would include the old interface at the top). A plugin
could query for "ImageData2", and fall back on "ImageData" if the
newer API isn't supported.


I'm currently in the early stages of trying to get a quick
proof-of-concept in Chrome to see how this looks and feels. There are
a lot of open questions that have yet to be resolved. Are there early
comments on this direction?

Brett


More information about the plugin-futures mailing list