[npapi] Master bug to synchronize with npapi-sdk

• Component: WebCore Misc.
• Status: RESOLVED WONTFIX

Currently WebKit maintains its own npapi headers set. And it is difficult to use is for plugin development.
Is there any possibility to use official npapi-sdk svn and synchronize with it? http://code.google.com/p/npapi-sdk/

I saw several bugs with patches to do that, but none of them succeeded.

I'll try to gather all related bugs here.

Existing bug https://bugs.webkit.org/show_bug.cgi?id=38666 is resolved as fixed, but it is not. And I wouldn't close this bug until headers from http://code.google.com/p/npapi-sdk/ are taken from its trunk (maybe with help of svn externals).

[Stuart Morgan]

> And it is difficult to use is for plugin development.

Why would you use it for plugin development? The whole point of the npapi-sdk project is that plugin developers can (and should) use those headers instead of using one random browser's headers.

> Existing bug https://bugs.webkit.org/show_bug.cgi?id=38666 is resolved as fixed, but it is not.

FWIW, I closed that bug because I got from "wildly different" (to the point that diffing the files was essentially meaningless) to "specific points of divergence", after which point having a meta-bug was not particularly useful.

> And I wouldn't close this bug until headers from http://code.google.com/p/npapi-sdk/ are taken
> from its trunk (maybe with help of svn externals).

That makes this bug uncloseable. Source-compatibility is not a requirement for the npapi-sdk project, which means that if a project always pulls trunk then it is subject to breakage at any moment for reasons beyond its control. It also makes building a specific older revision of the project as it existed at that time impossible. Doing that in WebKit would be a *terrible* idea. The best-case scenario for browser vendors would be to pull specific revisions, using something like Chromium's DEPS system.

>> Source-compatibility is not a requirement for the npapi-sdk project
>> The whole point of the npapi-sdk project is that plugin developers can (and should) use those headers instead of using one random browser's headers.

Well, you may be right, but as specified in https://wiki.mozilla.org/NPAPI#NPAPI_SDK the goal of this project is to use the header files to develop not only NPAPI plugins, but browsers as well. And "[they] are working on standardizing [headers] (the major differences are source-compatibility issues)." Did I misunderstand something?

>> The best-case scenario for browser vendors would be to pull specific revisions, using something like Chromium's DEPS system.

Yes, of course I meant to pull the specific revision from the "trunk" folder.

[Stuart Morgan]

(In reply to comment #3)
> Did I misunderstand something?

No, "the whole point" was poor word choice. npapi-sdk has a few major goals:
1) Have a single source of "truth" for these headers, which is always up to date with the latest NPAPI spec changes.
2) Give plugin developers a single source for headers that they should use in development
3) Make it easy for browser developers to maintain their headers.

The less forking there is in the browser sources, the easier 3 is for the browser vendors, thus bug 38666 and follow-ups (and all the similar work I did in Chromium).


I'm not arguing that continuing unforking is a bad idea; obviously I don't think that or I wouldn't have filed the follow-up bugs. I'm just confused about the assertion that doing so would help plugin development; given 1 and 2, plugin developers should *not* be using the WebKit project as a source of NPAPI headers. There shouldn't be any reason for anyone not maintaining the WebKit NPAPI implementation to care about WebKit's copies of these headers at this point.

[Ahmad Saleem]

Can we close this master bug and all dependent bugs since NPAPI plugins are not supported in Safari since version 14 and in Webkit ports (e.g. WebkitGTK)?

If they are supported in any Webkit port, please ignore my comment. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/95558668>