Re: Fetch API

On Mon, Jun 9, 2014 at 8:52 PM, Ali Alabbas <alia@microsoft.com> wrote:
> We (MS) reviewed the Fetch API and had the following questions/notes from our discussion:

Awesome, thanks!


> Is there an algorithm (such as SCA) that will be used to serialize these objects so that they may be persisted in the Cache?

Yes, we need to define how they can be structured cloned. I haven't
gotten around to it yet. Mostly been working on the basics. The main
problem with structured clones will be figuring out how that should
work with streams.


> 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.

It simply copies at that point. There's no nesting or pointers involved.


> * One could do this:
>
> var request1 = new Request("http://www.example.com/");
> var request2 = new Request(request1);
> var request3 = new Request(request2);
> fetch(request3);

Yeah, this works through copying the data. No pointers.


> 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.

We have changed members to be readonly for now. We can later consider
opening that up a bit, but that requires very careful reasoning on the
effects.


> 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.

You mean for XML documents? I suppose we could offer XML and HTML
features in due course. My idea was to grow the API slowly. See what
web developers build with it first and then add the low hanging fruit.
There's already a ton for implementers to do.


> 5. Also, are we considering support for "streams" as another type in the FetchBodyType?

The current idea is that .body will eventually return an actual
stream. For now it returns an object that exposes a to() method. That
to() method basically reads until the end of the stream and converts
the data. Once we get actual JavaScript IO streams we can refactor
this object with a to() method to be a subclass of such an IO stream.
I'm coordinating with Domenic who is working on JavaScript IO streams
to make sure this all works.


-- 
http://annevankesteren.nl/

Received on Monday, 9 June 2014 20:02:41 UTC