W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [futures] Persistent/Repeated Future that doesn't resolve

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 16 Apr 2013 00:17:57 +0200
Message-ID: <CA+c2ei9ZtzZPx4eFxAeTcg3aTw-L1eFeVMCej-svOrQ68mNjFA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Jake Verbaten <raynos2@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, "www-dom@w3.org" <www-dom@w3.org>
On Mon, Apr 15, 2013 at 12:10 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Sat, Apr 13, 2013 at 10:47 PM, Jake Verbaten <raynos2@gmail.com> wrote:
>>> Because Dart Streams clearly do give
>> you the whole history, according to the examples on the page Domenic
>> linked.
>>
>> I would interpret this as `when you call listen()` it starts emitting
>> events. If you call `listen()` multiple times it will throw an exception
>> unless it's in "broadcast" mode.
>
> Note that for XMLHttpRequest the Stream would need to keep an internal
> queue. You cannot just pipe the events through from the StreamWriter.
> The first person to get hold of the object should be able to get
> everything from the beginning. And if it's turned into a
> BroadcastStream at that point in time, I reckon the same should hold
> for everyone? Or maybe instead of BroadcastStream we should make a way
> to clone a Stream that includes its current queue.

The type of Stream returned from XMLHttpRequest and the type of Stream
discussed here are quite different.

XHR returns a stream of bytes, which can potentially be very large in
number. I.e. upwards of several MB is something that the API needs to
scale to well. Hence being able to deliver the contents of the stream
in "chunks", rather than one byte at a time, seems like a requirement.
Returning the data in the form of several ArrayBuffers seems like a
good default. Potentially allowing the reader to define how much data
to consume each time.

The stream discussed in the beginning of this thread instead contains
a, usually, smaller set of values. These values should likely at least
by default be delivered one at a time. Though we could possibly allow
the consumer to choose to request a set number of values each time.

Rather than calling this a "stream" I would call it an asynchronous
cursor or asynchronous iterator.

/ Jonas
Received on Monday, 15 April 2013 22:18:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC