Using npapi sdk in browser code. NP_* functions

[GoogleCodeExporter]

I don't quite understand how it's possible to use npapi-sdk for browser 
development.

The problem is in NP_Initialize, NP_Shutdown, NP_GetMIMEDescription and other 
NP_* functions.

As defined in npfunctions.h they are exported. But when a browser includes 
npfunctions.h and compiles it will encounter linking errors because NP_* 
functions are not defined in browser's code (and they shouldn't). How is this 
supposed to work? Maybe some define guard should be introduced?

Original issue reported on code.google.com by Van...@gmail.com on 27 Jan 2012 at 12:43

[GoogleCodeExporter]

Josh, this is part of the whole section that I don't think should be in the 
file, and doesn't exist in the WebKit and Chromium versions. Why does Gecko 
need it, and can it be moved to another file?

Original comment by stuart.morgan on 28 Jan 2012 at 8:21

[GoogleCodeExporter]

We do use them in Gecko, but we can probably just move that stuff to another 
file. I'd probably r+ a patch for npapi-sdk that removed the definitions. A 
patch may need to fix sample code in npapi-sdk.

Original comment by josh....@gmail.com on 29 Jan 2012 at 4:18

[GoogleCodeExporter]

There might be justification for not separating function pointers typedefs from 
function's declarations, in that if function declaration changes, appropriate 
typedef should also change. But NP_* functions will hardly ever change, so 
separation will probably make no harm.

As of how to implement it, there are two options: define guard or separate file.
With define guard approach there should be changes required for plugin side or 
browser side. With separate file approach there should be changes for plugin 
side.

I would not make changes required for plugin side because there are a way to 
more plugins than browsers, so I'd prefer the define guard approach. But the 
separate file approach is definitely better.

There can be a mix of those two:

We can add two files: npapi_plugin.h and npapi_browser.h. In one file there 
will be "define NPAPI_SDK_PLUGIN" and "define NPAPI_SDK_BROWSER" in another. 
npfunctions.h would generate an error if neither of these are defined.

Original comment by Van...@gmail.com on 29 Jan 2012 at 5:04

[GoogleCodeExporter]

I'm fine with the guards approach, that does make it easier for existing code. 
Lets not create any new files though. That's an unnecessary pain.

Thanks for looking into this.

Original comment by josh....@gmail.com on 29 Jan 2012 at 5:23

[GoogleCodeExporter]

Ok, so where such guard should be defined? In browser/plugin or both? I 
wouldn't change plugin code, not only because there are more plugins than 
browsers, but also because, IMO, a compile time error should be generated if 
client doesn't define a guard. What do you think?

Original comment by Van...@gmail.com on 29 Jan 2012 at 5:51