SDK 1.0 API proposal
Myk Melez
We've previously talked about what an SDK 1.0 release should comprise, and we've captured these goals in the SDK roadmap. One of them is "a carefully selected set of APIs that satisfies the common use cases of addons," and Dietrich has put together a list of APIs that have been suggested for this set.
Of those that haven't been implemented yet, here's the set of APIs that I think are important enough to enough actual and potential addon developers to warrant incorporating implementations into the core library of the 1.0 version of the SDK, which we plan to ship by the end of the year.
I've included explanations (of greater or lesser length depending on how likely I think the proposal is to be controversial). Keep in mind that this is just a first take. I'd love to get feedback on this proposal... What's missing from the list? What's on the list that shouldn't be? Your thoughts are prized!
Page Mods
Page Mods satisfies the Greasemonkey user script use case, which is one of the most popular ways of extending the browser.
Panel
Popup panels are becoming a more and more popular way to present transient information and request user input in Firefox, given their advantages over dialog boxes.
Places
The Places database is one of the primary sources of information about browsing behavior, and numerous existing addons use it to add interesting new features and enhance existing ones.
Windows
Application windows are a core feature of the browser (and underlying OSes), and though many users never use more than one, the edge cases for users who do (f.e. in terms of the behavior of tabs) are significant, as are the opportunities for interesting windows-based interfaces (even though many use cases are better satisfied by panels and sidebars).
Thus it's worth providing a basic windows API that gives developers access to the most common kinds of operations (activating windows, enumerating tabs in a specific browser window, etc.).
Sidebar
Sidebars are a bedeviling choice. Lamented by some Firefox contributors for not being useful and usable enough, Firefox's existing sidebar API nevertheless satisfies a use case that is not currently being served by another Firefox interface affordance and will not be satisfied by panels: that of a persistent, visible space that does not overlay other chrome.
The prototype had an API for sidebars, although it used its own experimental "slidebar" implementation. The SDK should also provide an API for adding sidebars, although its variant should integrate well with Firefox's existing sidebar implementation (with slidebar-like enhancements pushed into Firefox's implementation where appropriate).
Preferences
Traditional extensions use XUL dialogs to solicit preferences from users and typically store them in the application preferences store, while the prototype offered a high-level API that made soliciting a basic set of preferences much simpler.
Configuration is one of the more common tasks in which users engage when using addons, especially since addons often target users who are dissatisfied with the default features provided by the browser and thus amenable to configuring the browser (and its addons) to meet their needs.
So it's worth building a high-level API for soliciting basic preferences and then storing them in addon-specific storage (f.e. simple storage). We need to scope this carefully, however, because there are advanced features of such an API that it would be useful to have but which aren't necessary to support the common case of addons with simple preferences.
Keyboard Shortcuts
Most of the tasks that one can perform in Firefox have keyboard shortcuts associated with them, and power users (who are overrepresented among the ranks of addon users) often use them, so it should be possible for addons to register them.
Ideally, the API would identify conflicts and allow users to resolve them by customizing the shortcuts, but it is only the basic support for registering and using shortcuts that is really important for SDK 1.0.
Notifications
Transient notifications (of the growl and toaster varieties) and the Firefox notification bar have become popular ways to inform users about events and in some cases request responses. Some of the use cases for these notifications can be handled by panels, but others are better suited to the kind of affordance the notifications provide.
Clipboard
Clipboard access seems fairly popular amongst both traditional extensions and those created with the prototype, so it's worth providing an API for accessing the clipboard in the core library as well.
There are also a couple of APIs on Dietrich's list that I think we shouldn't prioritize for 1.0:
Database (SQLite)
SQLite is a popular way for Firefox features to store data, and addons also use it (although it's unclear how popular it is among addons). But it doesn't seem essential to the vast majority of addons, which either don't need to persist data or can use simpler mechanisms like the simple-storage API for doing so.
It seems like we'd be better off encouraging usage of simple-storage and enhancing the simple-storage API where appropriate to meet any additional use cases identified by developers before we start considering an API for creating SQLite databases.
Menus
Menus are becoming less prominent in Firefox 4, and at the same time the SDK is providing ways for addons to solicit interactions from users (like the widget API) that don't require them to choose a location in a menu (which users then have to find from amongst the many options in those menus).
It seems like we'd be better off encouraging addons to use widgets and other high-level APIs (f.e. sidebar) that in some cases may add menu items (for accessibility or consistency with existing Firefox implementations) than to give addons a "high-level" that provides direct access to menus themselves.
Note: just because I think we shouldn't prioritize database and menu APIs for 1.0, it doesn't necessarily mean I wouldn't accept an implementation of one of them for this release, just that I don't think they are ones on which we should focus our time and energy, and it would be better to first collect use cases of SDK-based addons that directly access the underlying Mozilla platform to do database/menu work before deciding to build an API for doing so.
Thoughts?
-myk
Hernan Rodriguez Colmeiro
> I've included explanations (of greater or lesser length depending on how
> likely I think the proposal is to be controversial). Keep in mind that this
> is just a first take. I'd love to get feedback on this proposal... What's
> missing from the list? What's on the list that shouldn't be? Your thoughts
> are prized!
>
I think the list is pretty comprehensive and covers the most use
cases, I just have a question regarding this:
> Sidebar
>
> Sidebars are a bedeviling choice. Lamented by some Firefox contributors for
> not being useful and usable enough, Firefox's existing sidebar API
> nevertheless satisfies a use case that is not currently being served by
> another Firefox interface affordance and will not be satisfied by panels:
> that of a persistent, visible space that does not overlay other chrome.
>
> The prototype had an API for sidebars, although it used its own experimental
> "slidebar" implementation. The SDK should also provide an API for adding
> sidebars, although its variant should integrate well with Firefox's existing
> sidebar implementation (with slidebar-like enhancements pushed into
> Firefox's implementation where appropriate).
>
I remember that when the reboot started, there was a lot of discussion
around the sidebar. Almost everyone was saying that the sidebar
wouldn't be on the SDK, or at least not in the same way that in the
prototype. The thing was that practically every person that I showed
the sidebar was pleased with the experience, and also I was. So, what
is going to happen UX-wise with the sidebar? Will it be the same
experience but better implemented, and maybe changing firefox
implementation? Will it be radically different?
Hernán
Matěj Cepl
> Preferences
>
> Traditional extensions use XUL dialogs to solicit preferences from users
> and typically store them in the application preferences store, while the
> prototype offered a high-level API that made soliciting a basic set of
> preferences much simpler.
+1000 on this.
> Notifications
>
> Transient notifications (of the growl and toaster varieties) and the
> Firefox notification bar have become popular ways to inform users about
> events and in some cases request responses. Some of the use cases for
> these notifications can be handled by panels, but others are better
> suited to the kind of affordance the notifications provide.
What more do we need than something like
/**
* Show a system notification with the given message
*
* @param String or Object with a message to be shown in a default
* notification or object with properties title, icon, and body
* @return None
*/
exports.notification = function notification(msg) {
var body = msg;
var title = "Bugzilla Notification";
var icon = null;
if (typeof(msg) === "object") {
body = msg.body;
if ("title" in msg) {
title = msg.title;
}
if ("icon" in msg) {
icon = msg.icon;
}
}
try {
var classObj = Cc["@mozilla.org/alerts-service;1"];
var alertService = classObj.getService(Ci.nsIAlertsService);
alertService.showAlertNotification(icon, title, body);
return true;
} catch (e) {
console.error("Unable to display notification:", msg);
return false;
}
};
> Clipboard
>
> Clipboard access seems fairly popular amongst both traditional
> extensions and those created with the prototype, so it's worth providing
> an API for accessing the clipboard in the core library as well.
https://fedorahosted.org/bugzilla-triage-scripts/browser/lib/clipboard.js
Will we get official support for basic prompts? Something like
https://fedorahosted.org/bugzilla-triage-scripts/browser/lib/prompts.js
???
> It seems like we'd be better off encouraging usage of simple-storage and
> enhancing the simple-storage API where appropriate to meet any
> additional use cases identified by developers before we start
> considering an API for creating SQLite databases.
Isn't there some HTML5-ish structured storage available in FF4?
Matěj
--
Our lives are spectacles of powerlessness.
-- Richard Rohr
Matěj Cepl
>
> We've previously talked about what an SDK 1.0 release should comprise,
> and we've captured these goals in the SDK roadmap
BTW, one more question: it might be useful to have some
password/encrypted-storage management. Something like (most likely
better written) like
https://fedorahosted.org/bugzilla-triage-scripts/browser/lib/passwords.js
?
Matěj
--
There is no reason to suppose that most human beings are engaged
in maximizing anything unless it be unhappiness, and even this
with incomplete success.
-- Ronald Coase
Introduction to ``The Firm, the Market, and the Law''
Lloyd Hilaiel
On Jul 27, 2010, at 10:26 AM, Matěj Cepl wrote:
>> Notifications
>>
>> Transient notifications (of the growl and toaster varieties) and the
>> Firefox notification bar have become popular ways to inform users about
>> events and in some cases request responses. Some of the use cases for
>> these notifications can be handled by panels, but others are better
>> suited to the kind of affordance the notifications provide.
>
> What more do we need than something like
>
> /**
> * Show a system notification with the given message
> *
> * @param String or Object with a message to be shown in a default
> * notification or object with properties title, icon, and body
I'd suggest:
+ @callback - An optional javascript callback to be invoked when user clicks on
notification
appears to already be supported in the underlying nsIAlertsService...
lloyd
Myk Melez
> So, what
> is going to happen UX-wise with the sidebar? Will it be the same
> experience but better implemented, and maybe changing firefox
> implementation? Will it be radically different?
existing sidebar implementation in Firefox, so the behavior of sidebars
added by Jetpack-based addons is consistent with the behavior of core
Firefox sidebars.
We should also identify key improvements in the slidebar prototype and
get those landed into Firefox, so all sidebars (whether added by addons
or built into Firefox) can benefit from them. But that can be a separate
project, and it'll be much easier to work on it separately than to try
to land its Firefox changes in conjunction with the SDK API.
-myk
Matěj Cepl
> I'd suggest:
>
> + @callback - An optional javascript callback to be invoked when user clicks on
> notification
>
> appears to already be supported in the underlying nsIAlertsService...
https://fedorahosted.org/bugzilla-triage-scripts/ticket/33
--
He uses statistics as a drunken man uses lamp-posts... for
support, rather than illumination.
-- Andrew Lang
Matěj Cepl
> notification
>
> appears to already be supported in the underlying nsIAlertsService...
What do you think about
https://fedorahosted.org/bugzilla-triage-scripts/changeset/640b26f
(note, I would rather not add too many parameters to that function)?
Matěj
--
If Patrick Henry thought that taxation without representation was
bad, he should see how bad it is with representation.
Dietrich Ayala
removed from the 1.0 list, I've removed them.
https://wiki.mozilla.org/Labs/Jetpack/SDK/APIs#High-level_APIs
> --
> You received this message because you are subscribed to the Google Groups
> "mozilla-labs-jetpack" group.
> To post to this group, send email to mozilla-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jet...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
>
Drew
look at what Alex Faaborg posted to dev-planning yesterday:
http://groups.google.com/group/mozilla.dev.planning/msg/3944d42aaf874b49
He's recommending two main points where extensions should add UI to
Firefox 4: 1) the extension bar and 2) an extension area in the Firefox
menu.
If that's what UX recommends for Firefox 4 extensions, Jetpack SDK 1.0
should definitely provide API(s) for both parts. The widget module
already handles part 1. Part 2 should be really simple. While it hooks
into the Firefox menu, it doesn't require a full-blown menu API, and it
might be even possible to handle it as a part of widget: Register a
widget, get a menu item for free.
(I'm not actually sure how a user can be guaranteed the experience Alex
describes for part 2 unless all the user's extensions are Jetpack-based...)
Drew
Aza
-- aza | ɐzɐ --
Drew
here means easy access to any menu anywhere.
IIRC from the Prototype, context menus were widely used, yes, toolbar
menus less so. Given that observation, and the UX recommendation that
Firefox 4 extensions restrict themselves to an extensions area of the
Firefox menu, and the fact that the SDK allows anyone to write and share
libraries, I think it's reasonable to focus on other things for SDK 1.0.
Plus what Myk said. :)
Drew
Dietrich Ayala
Firefox menu, and if that lands, it'll likely be one of the
"locations" a widget can be set to appear.
Myk Melez
Will we get official support for basic prompts? Something like
https://fedorahosted.org/bugzilla-triage-scripts/browser/lib/prompts.js
Isn't there some HTML5-ish structured storage available in FF4?
If we identify a more advanced form of storage as a common enough need for addon developers, IndexedDB seems like a better approach (because it is a web technology and more JavaScripty) than a raw SQLite API.
-myk
Myk Melez
> BTW, one more question: it might be useful to have some
> password/encrypted-storage management.
with which users have accounts, like Twitter and Bugzilla.
-myk
Myk Melez
If that's what UX recommends for Firefox 4 extensions, Jetpack SDK 1.0 should definitely provide API(s) for both parts.
The widget module already handles part 1. Part 2 should be really simple. While it hooks into the Firefox menu, it doesn't require a full-blown menu API, and it might be even possible to handle it as a part of widget: Register a widget, get a menu item for free.
(I'm not actually sure how a user can be guaranteed the experience Alex describes for part 2 unless all the user's extensions are Jetpack-based...)
-myk
Myk Melez
> IIRC from the Prototype, context menus were widely used, yes, toolbar
> menus less so. Given that observation, and the UX recommendation that
> Firefox 4 extensions restrict themselves to an extensions area of the
> Firefox menu, and the fact that the SDK allows anyone to write and
> share libraries, I think it's reasonable to focus on other things for
> SDK 1.0. Plus what Myk said. :)
Also, in my experience, addons typically only modify the Tools menu,
adding a single menu item (perhaps with sub items) that serves as an
interface to the extension's functionality. So the kind of "menu" API it
would make sense to support would be a targeted one that satisfies this
common use case (as opposed to a generic one for general menu manipulation).
And given recent Firefox proposals for an addons submenu of the Firefox
menu, this sounds like exactly what we should do.
-myk
Julián Ceballos
with you. i'd like to apologize, and say i'm sorry for my wrong way to
try to contribute with you, i'll help since right now in the correct way
to help you in this project that i like so much. =)
--
Juli�n Ceballos
Mozilla M�xico Software
Julián Ceballos
says that it would be add at the firefox 4 version, where do you think
it woul be?
Myk Melez
> Hi folks, you've made me see that i was in a wrong way to contribute
> with you. i'd like to apologize, and say i'm sorry for my wrong way to
> try to contribute with you, i'll help since right now in the correct
> way to help you in this project that i like so much. =)
No need to apologize, you did nothing wrong! Writing a JEP and filing a
bug are perfectly valid ways to contribute an API to the project! I only
suggested what I did because I think a library in the Add-on Builder
will be a better way to develop this particular API.
(In general, Add-on Builder libraries are the better way to develop most
APIs, since one doesn't have to write a spec beforehand, conform to core
code and API design standards, go through design and implementation
review cycles, and release on a schedule.)
Nevertheless, it's perfectly reasonable to have started with a JEP and
bug, so don't worry, you did everything right, and I'm looking forward
to seeing your API evolve!
-myk
Myk Melez
> I have one question, talking about the IndexedDB, i see that in the
> MDN says that it would be add at the firefox 4 version, where do you
> think it woul be?
nightly builds, since evaluating "moz_indexedDB" in the Error Console
returns [object IDBFactory]. I'm not sure how to get it from a non-DOM
Window context like an SDK module, though. :-/
-myk