13
edits
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: | ||
* | * 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 | * 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. | ||
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. | |||
edits