Extension compatibility ideas: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 19: Line 19:
Here is a suggestion for how to address all these issues, in two parts:
Here is a suggestion for how to address all these issues, in two parts:


* Create an automated tool which, given an extension, attempts to scan for use of known-frozen/stable APIs versus "other" (i.e. functionality not known to be frozen/stable).  Use this tool as part of the a.m.o. submission process and stamp the results into the extension somewhere or into an accessible online database.
* Allow extension authors to provide a manifest of GUIDs, or something similar, they depend on. These are the actual interfaces they use.
** The results of this tool allow us to see, regardless of version string, that a specific extension is likely to still work with a newer Firefox, because none of its APIs have been broken.
** Either the browser itself, or else a.m.o. or similar need to be able to tell you whether a given Firefox release supports a particular set of IDs.
** An enhanced version of the tool, which records what APIs are actually used instead of just stable vs. unstable, could then be coupled with information about "these APIs have changed in this Firefox version" to also mark "compatible" extensions that use unstable but unchanged APIs.
** For people trying to be compatible with multiple versions, there may need to be more complex behavior than a simple list, such as "ID x and (y or z)".
** Currently, this tool will not be much use, because a very small set of functionality is actually stable, and even common tasks like creating XUL overlays might trigger the "unstable" flag.
** Some things people want to do may not currently correspond to actual APIs/interfaces/things with GUIDs. Perhaps we'd need to encapsulate some "non-API" concepts in here?
** This tool is nontrivial to create.
** Perhaps an automated tool (nontrivial!) could be written to generate a list of GUIDs from some code, in order to ease manifest creation?  This is probably too hard to be worth it
* Use the automated tool as a reward path to get people to use stable APIs (since their extensions will no longer break), and make that an achievable goal by beginning to standardize more functionality.
* Use a known, publicized set of "stable interface GUIDs" as a reward path to get people to use stable APIs (since their extensions will no longer break), and make that an achievable goal by beginning to standardize more functionality.
** Supposedly, IE has a richer set of public APIs for folks writing extensions/BHOs.  Perhaps we could learn from what they've done.
** Supposedly, IE has a richer set of public APIs for folks writing extensions/BHOs.  Perhaps we could learn from what they've done.
** A standardized way to, say, add an item to a menu means we can enforce more UI consistency.  Carefully chosen APIs mean we can also discourage dangerous or less-usable functionality/design.
** A standardized way to, say, add an item to a menu means we can enforce more UI consistency.  Carefully chosen APIs mean we can also discourage dangerous or less-usable functionality/design.
** Because "unstable" extensions still work, there's no need to try and provide a frozen interface to everything anyone could possibly want; we can cherry-pick desired functionality and provide it at any desired pace.  Thus this design doesn't require a lot of "big bang" implementation and allows us to proceed carefully on the API work.
** Because "unstable" extensions still work, there's no need to try and provide a frozen interface to everything anyone could possibly want; we can cherry-pick desired functionality and provide it at any desired pace.  Thus this design doesn't require a lot of "big bang" implementation and allows us to proceed carefully on the API work.


And now some more editorial comments from me (pkasting): I proposed something like this on #developers and received a lukewarm reception, but I suspect that was due to
Manpower is always a problem when tackling issues like this, but the current human interaction model isn't working and doesn't scale.  An automated system that, if necessary, falls back on the version numbering system we have now would be a strict improvement.
* Only speaking of the automated tool portion, not the stable API reward path portion
* General reluctance on the part of developers to go anywhere near ideas like "stable APIs"
* A lack of developer interaction with extension developers, and a lack of understanding of the problems of extension developers
 
I'm certainly open to suggestions on how the problems I give at the beginning can be addressed, but I think they do _need_ to be addressed.  The human interaction model we have now clearly does not work well enough to prevent a lot of user frustration among extension users, and I think it lowers the numebr and quality of extensions as well.  While the ideas described here would take a great deal of effort to implement, I think they would be worth persuing over the course of several release cycles.

Revision as of 22:47, 5 May 2006

There are currently a lot of problems with extension compatibility in Firefox.

  • Versioning was introduced to allow continued API flexibility, but it doesn't solve the problem well
    • Because things can change in arbitrary ways between releases, authors must retest their extensions and attempt to observe if things still work
    • Older extensions naturally rot and become prematurely unusable unless they're continually maintained
    • The requirement for human interaction means Firefox does not tell users if an extension is _actually_ incompatible, only if someone has manually marked it _compatible_, which isn't the same
  • Users do not understand this issue and it negatively impacts their behavior
    • Firefox appears to tell them extensions are _actually_ incompatible, which makes them believe they truly are more than is really the case, which makes them believe extensions aren't ever going to be compatible with any upgrades
    • Users using extensions care a lot about their extensions, so this means they don't like upgrades, since upgrades (that they aren't eager for) have always broken their extensions
    • The dislike for upgrades, coupled with the frustration of the browser "breaking my extensions all the time", lead to lowered user satisfaction and less security

So, the ideal solution would be "never break extensions" and the less-ideal, but still improved solution, would be "make Firefox say my extension is incompatible if and onyl if it is actually incompatible". Our current system makes no attempt at the first of these, and only accomplishes the second with significant and continued human interaction.

In addition, extension authors don't have a well-specified "best way" of doing various common tasks, which is also a negative:

  • Authors need to research how to do things instead of using simple, available documentation
  • Authors do things many different ways, possibly causing obscure bugs by hooking into seldom-used or unintentionally public functionality
  • There is no consistency between extensions and the browser or extensions and each other in terms of the user experience

Here is a suggestion for how to address all these issues, in two parts:

  • Allow extension authors to provide a manifest of GUIDs, or something similar, they depend on. These are the actual interfaces they use.
    • Either the browser itself, or else a.m.o. or similar need to be able to tell you whether a given Firefox release supports a particular set of IDs.
    • For people trying to be compatible with multiple versions, there may need to be more complex behavior than a simple list, such as "ID x and (y or z)".
    • Some things people want to do may not currently correspond to actual APIs/interfaces/things with GUIDs. Perhaps we'd need to encapsulate some "non-API" concepts in here?
    • Perhaps an automated tool (nontrivial!) could be written to generate a list of GUIDs from some code, in order to ease manifest creation? This is probably too hard to be worth it
  • Use a known, publicized set of "stable interface GUIDs" as a reward path to get people to use stable APIs (since their extensions will no longer break), and make that an achievable goal by beginning to standardize more functionality.
    • Supposedly, IE has a richer set of public APIs for folks writing extensions/BHOs. Perhaps we could learn from what they've done.
    • A standardized way to, say, add an item to a menu means we can enforce more UI consistency. Carefully chosen APIs mean we can also discourage dangerous or less-usable functionality/design.
    • Because "unstable" extensions still work, there's no need to try and provide a frozen interface to everything anyone could possibly want; we can cherry-pick desired functionality and provide it at any desired pace. Thus this design doesn't require a lot of "big bang" implementation and allows us to proceed carefully on the API work.

Manpower is always a problem when tackling issues like this, but the current human interaction model isn't working and doesn't scale. An automated system that, if necessary, falls back on the version numbering system we have now would be a strict improvement.