- From: Ali Alabbas <alia@microsoft.com>
- Date: Mon, 9 Jun 2014 18:52:04 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, public-script-coord <public-script-coord@w3.org>, Joshua Bell <jsbell@chromium.org>, Jungkee Song <jungkee.song@samsung.com>, Yehuda Katz <wycats@gmail.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>, Jake Archibald <jaffathecake@gmail.com>, Tobie Langel <tobie.langel@gmail.com>
- CC: WebApps WG <public-webapps@w3.org>
We (MS) reviewed the Fetch API and had the following questions/notes from our discussion: 1. From previous discussions, our understanding is that the there is a need to persist Response objects so they can be replayed offline in a Service Worker. This implies that the Response and Request objects are expected to be stored in persistent storage such as the Cache (see: http://www.w3.org/TR/2014/WD-service-workers-20140508/#cache) or IDB. The Response objects would be the value in the Cache map and the Request objects would be the key to access the Response. We imagine that these objects need to be serialized in order to be stored. Is there an algorithm (such as SCA) that will be used to serialize these objects so that they may be persisted in the Cache? This wasn’t defined in the spec. 2. Is there a scenario where we would want to have a Request inside of a Request? It appears that one could construct a Request and pass in a RequestInfo as input which is defined as either a Request or ScalarValueString. * One could do this: var request1 = new Request("http://www.example.com/"); var request2 = new Request(request1); var request3 = new Request(request2); fetch(request3); 3. Are there scenarios where once you set the Request url, we would change it before fetching? If not, the url could be readonly. Otherwise, it could be optional in the constructor as it could always be defined later. * e.g. if we could the following: var request = new Request("http://www.example.com/"); request.url = "http://www.foo.com"; fetch(request); * why not just allow this (url is optional): var request = new Request(); request.url = "http://www.foo.com"; fetch(request); * otherwise, make it readonly: var request = new Request("http://www.example.com/"); // not allowed: request.url = "http://www.foo.com"; fetch(request); 4. Are we expecting to build XML content types using the “text” body type? It would be nice if we directly supported “xml” and included them in the FetchBodyType enum. * e.g. enum FetchBodyType { "arraybuffer", "blob", "json", "text", "xml"}; 5. Also, are we considering support for "streams" as another type in the FetchBodyType? Our apologies if these questions have been asked before. Thank you, Ali -----Original Message----- From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren Sent: Thursday, May 29, 2014 5:57 AM To: public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell; Jonas Sicking; Jake Archibald; Tobie Langel Cc: WebApps WG Subject: Fetch API The plan is to implement and ship this fairly soon, so I figured I'd ask for review now, while we're still drafting the text: http://fetch.spec.whatwg.org/#fetch-api In particular I'd like feedback on the design of Request and Response classes, and the fetch() method. -- http://annevankesteren.nl/
Received on Monday, 9 June 2014 20:22:44 UTC