855936 - Utilize Node.js APIs in the SDK wherever possible

Status: RESOLVED WORKSFORME

(Add-on SDK Graveyard :: General, enhancement)

Description

[Brett Zamir]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130328 Firefox/22.0
Build ID: 20130328031013




Expected results:

In the interest of seeing harmonization of APIs across the web ecosystem, I would like to suggest consideration of the possibility of using Node.js APIs within the SDK wherever possible (or even work together with Node.js on ensuring this where possible).

The benefits of harmonization could include easier uptake of the SDK by newcomers, easier learning of Node.js by SDK users, and code reuse (e.g., a desktop browser GUI).

I envision this may be possible with non-browser-specific functionality such as file APIs, possibly database APIs, and even server-specific APIs (where Mozilla is becoming usable as a server: https://developer.mozilla.org/en-US/docs/Httpd.js/HTTP_server_for_unit_tests ).

For those thinking that CommonJS may be a better target for harmonization, see https://github.com/joyent/node/issues/5132 where most (including apparently key members of Common.js) appear to agree that Node.js is now THE SSJS target.

Comment 1

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Whenever we're adding new APIs I agree we should look for existing implementations and just use those assuming they meet our licensing requirements. I'm not sure there is anything specific to do for this bug though

Comment 2

[Brett Zamir]

Sorry to respond late on this, but my idea was to harmonize the _existing_ SDK API with the Node.js API (even via adapters to allow the old API to continue to work).

Comparing http://nodejs.org/api/fs.html and https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/io/file.html , for example, one sees Node's readFile which is similar to the SDK's read (but which allows co-existence with (Node's) more granular "file" method), as well as other APIs which would be useful to implement (e.g., "rename").

The idea is not simply to learn from other APIs but to actually be able to inter-operate with them as much as possible.

(FYI, Bug 880908 would allow similar interoperability but with regular web app code.)

Comment 3

[Brett Zamir]

Sorry to respond late on this, but my idea was to harmonize the _existing_ SDK API with the Node.js API (even via adapters to allow the old API to continue to work).

Comparing http://nodejs.org/api/fs.html and https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/io/file.html , for example, one sees Node's readFile which is similar to the SDK's read (but which allows co-existence with (Node's) more granular "file" method), as well as other APIs which would be useful to implement (e.g., "rename").

The idea is not simply to learn from other APIs but to actually be able to inter-operate with them as much as possible.

(FYI, Bug 880908 would allow similar interoperability but with regular web app code.)

Comment 4

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Again I'm still not sure what steps specifically we could take here. If you're asking to land APIs that match node's then we can evaluate those on a case by case basis, we just laded a match for their fs module f.e.

Comment 5

[Brett Zamir]

Yes, I was asking to land APIs that match Node's. I see https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/fs/path.js but I was hoping for entire fs module support (at least the non-server-specific stuff).

I'd like to be able to make a file browser, for example, which works on either local files or remote ones.

(And other modules would be great--even the server-specific ones might work as APIs for your built-in server.)