Comments (12)
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
from npapi-sdk.
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 [email protected]
on 6 Sep 2011 at 6:52
from npapi-sdk.
> 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
from npapi-sdk.
> 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 [email protected]
on 6 Sep 2011 at 1:32
from npapi-sdk.
> 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
from npapi-sdk.
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 [email protected]
on 6 Sep 2011 at 2:22
from npapi-sdk.
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 [email protected]
on 6 Sep 2011 at 2:24
from npapi-sdk.
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 [email protected]
on 6 Sep 2011 at 2:29
from npapi-sdk.
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 [email protected]
on 6 Sep 2011 at 3:41
from npapi-sdk.
> 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
from npapi-sdk.
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 [email protected]
on 7 Sep 2011 at 7:34
from npapi-sdk.
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
from npapi-sdk.
Related Issues (20)
- Please add NPAPI_VERSION_REVISION to provide true API version number HOT 2
- add support for NPNVdocumentOrigin HOT 2
- Samples unix-basic BasicPlugin not working HOT 7
- NP_GetPluginVersion has incorrect const-ness HOT 1
- NP_VERSION_MINOR must be increased HOT 1
- Using npapi sdk in browser code. NP_* functions HOT 5
- Const correctness of some functions' arguments HOT 2
- [patch] Can ndata be const void *? Is it used anywhere? HOT 1
- NP_* function declarations are declared with calling convention incompatible with NP_*Func types HOT 3
- Code review request HOT 2
- add support for Asynchronous Drawing Models (Bitmap and Windows Accelerated) HOT 7
- Fix a calling convention of NPN_* function pointers HOT 11
- Patch for /trunk/samples/mac-basic/Info.plist HOT 1
- Under MinGW bool and uintptr_t are unknown type names HOT 3
- OpenGL.h include in npapi.h on mac is problematic for some users HOT 4
- Plugin compiles but plugin error when loaded
- Need a tutorial or sample code to develop NPAPI Plugin for Safari5.1 from scratch HOT 1
- add a pkgconfig template HOT 6
- Add a simple autotools buildsystem HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from npapi-sdk.