Extension compatibility ideas: Difference between revisions

Extension compatibility ideas (view source)

Revision as of 22:47, 5 May 2006

911 bytes removed , 5 May 2006

no edit summary

Pkasting

13

edits

@@ Line 19: / Line 19: @@
 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.
 ** 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.
-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.