595386 - make high-level "web" module to provide web-compatibility APIs

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Myk Melez [:myk] [@mykmelez]]

Most of the SDK's modules fall into one of two categories:

1. "high-level modules" for addon developers, whose interfaces have been designed for simplicity, ease of use, and consistency across the category;

2. "low-level modules" for library developers, whose interfaces have been designed for control and flexibility.

Over in bug 592848, we plan to distinguish between these two sets of modules in order to emphasize the high-level ones to addon developers.  However, there is at least one module, "xhr", that is in a third category:

3. "web-compatibility modules" for addon developers familiar with the web platform, whose interfaces are identical to web platform APIs.

Modules in the third category don't easily fit into either the high- or low-level module categories, since they are intended for addon developers but lack some features of other high-level modules (like consistency) and/or duplicate functionality (as does "xhr" with the "request" module).

So Atul and I talked through this issue and concluded that the best solution would be for us to group web-compatibility modules with low-level modules when distinguishing them from high-level modules and then add a high-level "web" module that gives developers access to their functionality.

Thus, rather than advertising the "xhr" module to addon developers as one of two equally high-level ways to make network requests, we will advertise the "request" module as the high-level way to make network requests and the "web" module as the way to access web platform APIs like XMLHttpRequest.

Developers who prefer XMLHttpRequest to the "request" module (or for whom "request" does not yet satisfy their use case) can then access it via:

  var { XMLHttpRequest } = require("web");

And we can add other such APIs (f.e. [set|clear][Timeout|Interval]) to the "web" module as needed.

This bug doesn't depend on bug 592848, but the two are related, and while it doesn't need to be fixed in order for us to reach beta, it would be useful to fix the two in conjunction, and this one seems relatively easy to do.

So I'm marking this as P2 for 0.8, which is the release in which we plan to fix bug 592848 (which is marked as P1 for 0.8).

Atul: since you are assigned to fix bug 592848, can you take on this bug as well?

Comment 1

[Atul Varma [:atul]]

One funky thing I just realized about this module is that it semi-breaks the "manifest inference" functionality of the jetpack sdk: right now a single require("web") will only bring in timer and xhr, but in the future it could bring in other things that might bloat the authority of the addon. It's fixable if we have more powerful static analysis tools like DoctorJS on-hand, i think, which would e.g. allow us to see that an addon just uses require("web").XMLHttpRequest and create a manifest that still obeys POLA.

Since require("web") currently only brings in timer and XHR though, I think we should be okay for the time being, just wanted to note it as a potential concern in the future.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Developers don't seem to be breaking down the door for this, and a better solution would be to give addons that want it a real web DOM environment, so let's not do this.