581560 - Add async version of Labs' resource.js next to NetUtil.jsm

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

It exposes a nice API for simple HTTP (only, for the moment) requests:

var resource = new Resource("http://example.com");
resource.get(function (result) {
  print(result); // string containing HTML source
  print(result.status); // 0 (nsresult)
  print(result.success); // true (boolean)
);

resource.setHeader("Content-Type", "application/x-www-form-urlencoded");
resource.post("foo=bar", function (result) {
  // Same as above
});

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Attachment: WIP

Will take a look at porting some of the tests from test_resource.js.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Attachment: updated WIP

Some minor changes. Still needs tests based on http://mxr.mozilla.org/mozilla-central/source/services/sync/tests/unit/test_resource.js .

Comment 3

[Ed Lee :Mardak]

Attachment: v1

Comment 4

[Ed Lee :Mardak]

Attachment: v1.1

Oops, thought I removed the ignore caching bits.

Comment 5

[Ed Lee :Mardak]

Attachment: v2

Dan added the ability to set load flags.

Comment 6

[Shawn Wilsher :sdwilsh]

I can probably do this review if bz or biesi are OK with it.  I tend to do the reviews of NetUtil.jsm and bz or biesi do the sr.

Comment 7

[Philipp von Weitershausen [:philikon]]

FWIW, I've filed (and implemented) bug 603301 to provide an async version of Resource in services/sync.

It differs from the implementation in this bug in that it still contains the Firefox Sync specific additions. It also has a different signature for the callback, adopting the node.js convention of passing any errors/exceptions into the callback as the first argument and results as second and further arguments. I personally think this makes for a clearer API than sticking attributes on a String object. I would welcome if the netwerk version would adopt the same signature, but it's cool if not. For now we Sync needs to stick with its own implementation anyway, at least as long as we still continue to support Firefox 3.5/3.6.

Comment 8

[Philipp von Weitershausen [:philikon]]

We've found that the Resource implementation, even the async one as described in comment 7, is lacking some crucial features which is mostly due to poor API design. Bug 669547 explains the details and also has a new alternative implementation called RESTRequest (which is inspired by Resource a lot.)

I hereby propose RESTRequest to be uplifted to either network or toolkit (e.g. into mozapps/shared), rather than Labs' Resource. Sync is definitely going to abandon Resource in favour of RESTRequest.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 469307 [details] [diff] [review]
v2

r- given comment 8