Observables: buffering
I just watched Jafar Husain's talk on the future of JavaScript: www.youtube.com/watch?v=3pKNRgResq0
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.
—Regis
I just watched Jafar Husain's talk on the future of JavaScript: www.youtube.com/watch?v=3pKNRgResq0
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.
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.
—Regis
I just watched Jafar Husain's talk on the future of JavaScript: https://www.youtube.com/watch?v=3pKNRgResq0 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. —Regis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160917/0f964528/attachment.html>