Observables: buffering

Régis Kuckaertz regis.kuckaertz at gmail.com
Sat Sep 17 15:38:36 UTC 2016

I just watched Jafar Husain's talk on the future of JavaScript:

The addition of the observable pattern and composability across interfaces
are welcome additions to the language. I would like to suggest the addition
of *buffers*, a feature that is ubiquitous in all forms of I/O.

In its current form, the producer and consumer abide to a strict contract
where every value produced on the stream must be consumed, sequentially. In
many situations this is very inefficient. The producer and consumer rarely
work at the same pace.

It is not hard to imagine an example using DOM Events where the producer
works much faster than the consumer and *cannot* wait for the consumer: an
autocomplete widget, a parallax effect handler, a random number generator,
etc. Without a mechanism to control pace and back pressure, this is
extremely hard to do.

[Constructor(int bufferSize)]
interface BufferedObserver<T, BufferType> : Observer<T> {
  readonly attribute BufferType buffer;

Different types of data buffers (such as those available in Clojure's
core.async) could make this coding pattern extremely powerful, effectively
giving developers the means to write complex queueing algorithms without
much code; one could even imagine a future where buffers would be
effectively elastic and react to changes in the rate of incoming data.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160917/0f964528/attachment.html>

More information about the es-discuss mailing list