rev5 breaks API compatibility for plugins

[GoogleCodeExporter]

When trying to build icedtea-web NPAPI plugin with npapi-sdk:

/tmp/portage/dev-java/icedtea-web-1.1.1-r1/work/icedtea-web-1.1.1/plugin/icedtea
np/IcedTeaNPPlugin.cc: In function 'char* NP_GetMIMEDescription()':
/tmp/portage/dev-java/icedtea-web-1.1.1-r1/work/icedtea-web-1.1.1/plugin/icedtea
np/IcedTeaNPPlugin.cc:2266:24: error: new declaration 'char* 
NP_GetMIMEDescription()'
/usr/include/npapi-sdk/npfunctions.h:303:24: error: ambiguates old declaration 
'const char* NP_GetMIMEDescription()'

The change introduced in rev5 is causing this breakage. I'm not sure if it 
might not break ABI as well on some exotic arches.

My suggestions is reverting it now, and coming back to it when a good migration 
plan is established. If it's actually worth breaking that whole lot of packages.

For your convenience, attaching patches to revert the changes.

Original issue reported on code.google.com by mgo...@gentoo.org on 5 Sep 2011 at 7:36

Attachments:

• 0001-Revert-Make-NP_GetMIMEDescription-return-value-const.patch
• 0002-Revert-Fix-UNIX-sample-plugin-bustage.patch

[GoogleCodeExporter]

Source-level compatibilty is not a requirement for npapi.h. Occasionally when a 
plugin or browser vendor updates the headers they will need to make minor 
tweaks to source; it's happened before at it may well happen again.

Only binary compatibility is required, and constness does not affect binary 
compat. This change was made intentionally, and we have no plans to revert it. 
The migration plan, just as it has always been, is that when people update 
headers, they adjust their code as necessary. There's no reason for anyone to 
update their headers if they aren't already making code changes, so the burden 
on developers is minimal.

Original comment by stuart.morgan on 6 Sep 2011 at 5:01

• Changed state: WontFix

[GoogleCodeExporter]

I'm not sure about that binary compat. In C++, types affect symbol naming. I 
guess on some exotic platforms a similar thing may happen for C. There is a 
reason GCC treats this as an error, not a warning.

And if you really intend to do such changes and require people to update code, 
you should bump NPAPI version and describe the change as NPAPI used to. Or do 
you expect them to magically scan headers and determine which prototype to use?

Original comment by mgo...@gentoo.org on 6 Sep 2011 at 6:52

[GoogleCodeExporter]

> I guess on some exotic platforms a similar thing may happen for C.

A personal theory that it might theoretically be possible for this to be wrong 
is not a compelling argument. If you want this reverted based on binary 
compatibility grounds, you need to give a real example and/or a pointer to the 
relevant part of the C standard.

> you should bump NPAPI version

No, we shouldn't. NPAPI version changes happen when structures change size (and 
maybe some other very specific cases I'm not remembering at the moment).

> and describe the change 

So... you want a list of monotonically increasing numbers with change 
descriptions for every future change to the headers? In that case, I refer you 
to http://code.google.com/p/npapi-sdk/source/list

> Or do you expect them to magically scan headers

I expect developers to be able to read headers, yes. I don't believe it 
requires magic.

I'm confused why you think that nobody could possibly be capable of handling 
changes to the NPAPI headers given that it's worked this way for years. The 
recent creation of the npapi-sdk project improved the situation by making it so 
that developers didn't have to sift through three different browsers' source 
repositories to find each one's divergent copies of the headers and try to 
understand the differences between them all. The change to having a single 
upstream source means that there's a canonical set of headers, which makes 
things easier for everyone. Your apparent belief that a simplifying step has 
somehow made the whole process totally untenable for developers doesn't really 
make sense to me.

If you really want to challenge the way NPAPI changes are managed, the right 
place for that would probably be the relevant Mozilla development mailing list, 
not the bug tracker here.

Original comment by stuart.morgan on 6 Sep 2011 at 1:13

[GoogleCodeExporter]

> I expect developers to be able to read headers, yes. I don't believe it 
requires magic.

And how are developers supposed to determine whether NPAPI headers come from 
new version which does require them to use 'const' in function prototype, or 
the old one? Or you mean that no backwards compatibility is intended because 
so, and all packages should be turned upside down to use headers from a project 
which likes to change API even without bumping version.

Original comment by mgo...@gentoo.org on 6 Sep 2011 at 1:32

[GoogleCodeExporter]

> And how are developers supposed to determine whether NPAPI headers come from
> new version which does require them to use 'const' in function prototype, or 
the old one?

I don't really understand the question. The expected development model is:
1) At some point, a developer chooses to update their copy of the NPAPI headers
2) They may need to make some adjustments to their source when they do.
Yet again: this is the way NPAPI has worked since long before the npapi-sdk 
project existed. This project was started to simplify step 1 (as described in 
comment 3). That's it.

> Or you mean that no backwards compatibility is intended

Source-level backwards compatibility is not provided by the NPAPI headers (as I 
said earlier). Binary backwards compatibility is. That decision has nothing to 
do with the npapi-sdk project.

> and all packages should be turned upside down to use headers from a project 
which
> likes to change API even without bumping version

You don't seem to understand the different between the npapi-sdk project, and 
the development of NPAPI itself. Your issues with the way NPAPI is managed 
should be taken up on the appropriate Mozilla list.

Original comment by stuart.morgan on 6 Sep 2011 at 2:06

[GoogleCodeExporter]

I think maybe the perspective difference making it hard to see eye-to-eye here 
is that we assume NPAPI headers are part of the source of the project using 
them. The other guy is assuming they are part of a devel package which might be 
used for a number of packages on a system, in which version mixing is a bigger 
problem. It would be hard to code an NPAPI plugin to work against multiple 
versions of NPAPI headers.

If that is what is going on here, I understand the concern but that's not how 
NPAPI has worked and I don't see us changing. My recommendation would be that 
each plugin package include its own NPAPI headers, and updating them would be 
the responsibility of each plugin's maintainer. An npapi-devel package is just 
not going to work well with how we do things (we don't guarantee source compat 
or even make source compat easy).

Original comment by josh....@gmail.com on 6 Sep 2011 at 2:22

[GoogleCodeExporter]

So, it's like jumping from one swamp into another. The way OS projects work is 
a little different. People don't copy stuff over and over again for no reason; 
people package, install and reuse it. And a SDK package is supposed to supply 
projects with an ability to use any version without requiring bundling them 
with packages.

Other way, this project doesn't really make a difference. It just moves four 
files from one place to another without any real benefit. Except for the name.

Original comment by mgo...@gentoo.org on 6 Sep 2011 at 2:24

[GoogleCodeExporter]

We're talking about four or so header files that aren't even that large. You're 
not saving any significant amount of space (you're probably actually taking up 
more space) or gaining much of anything by having a devel package. I get the 
appeal, but it just doesn't matter much here compared to what we'd have to do 
to rectify the situation.

Original comment by josh....@gmail.com on 6 Sep 2011 at 2:29

[GoogleCodeExporter]

The idea of a devel package isn't about saving space but about consistency.  
Say that for some reason npapi.h was changed due to the way one of the 
functions were structured, providing what amounted to a security hole -- that 
change should be migrated everywhere, not just according to the whim of a 
developer that decides one day to update their plugin's embedded npapi.h.

Back to the original issue, i think it could be said that there is a difference 
between NPAPI version (which seems to be the ABI version, in fact) and NPAPI 
code revision (which is generally thought of as the API version); and what is 
needed here is a method of tracking (via the pkg-config file for instance) the 
code revision.  IE:  0.27.4 for the codebase not containing a const'd 
NP_GetMIMEDescription , 0.27.12 for the most recent revision , etc..  Using the 
actual commit revisions might not be a good idea; a release revision number 
instead would probably be better, that way newer changes (like addition of the 
pkg-config file) would be integrated into older release versions.

Original comment by i.staken...@gmail.com on 6 Sep 2011 at 3:41

[GoogleCodeExporter]

> It just moves four files from one place to another without any real benefit. 

Plenty of people have found benefit from this project. Some of the largest 
browser and plugin vendors among them. Please stop stating your own negative 
opinions about this project as objective facts; it's not helping your arguments 
at all.

> Say that for some reason npapi.h was changed due to the way one of the 
functions
> were structured, providing what amounted to a security hole -- that change 
should
> be migrated everywhere

Assuming for a moment such a change were even possible, "migrated everywhere" 
in the context of an NPAPI plugin means the plugin vendor updating their 
source, building and packaging a new plugin, and shipping it to users. How the 
npapi-sdk project does (or doesn't) version headers wouldn't have any impact 
there.

Original comment by stuart.morgan on 7 Sep 2011 at 7:06

[GoogleCodeExporter]

On Wed, 07 Sep 2011 07:07:03 +0000

And that's why Firefox6 still ships NPAPI headers without your 'const'
modification?

And how about users using an older plugin version? Or are they all
forced to migrate to the new version just because you are unable to get
the basic concepts of OSS development? Why is plugin vendor supposed to
have additional work because of *your* mistake?

Original comment by mgo...@gentoo.org on 7 Sep 2011 at 7:34

[GoogleCodeExporter]

You clearly do not understand the relationship between this project, browser 
vendors, and NPAPI development. You also seem to be willfully ignoring the 
distinction between source and binary compatibility. Given that, continuing 
this discussion is not productive.

Original comment by stuart.morgan on 7 Sep 2011 at 4:35

• Added labels: Restrict-AddIssueComment-Commit