Re: [filesystem-api] Observable is not appropriate for directory listing; async iterable would be better (#4)

> Correct me if I'm totally wrong on this, but it honestly does seem like both can be used for the primary use cases:

Both can be used, for sure. However, async iterables map more directly (in the sense of giving more control) than observables do. The async iterable to observable transformation is lossy, in the sense that to create an observable from an async iterable you have to pump the async iterable in a loop in order to "emit events" (i.e., call `next()` on the passed generator object), instead of waiting for the consumer to pull at the pace it desires.

> "Observable" lent itself to filtering and mapping.

As proposed to TC39, neither [async iterable](https://github.com/zenparsing/async-iteration/) nor [observable](https://github.com/zenparsing/es-observable) has filtering or mapping. But it is equally trivial to add filtering and mapping to either. (I kind of doubt either will happen before we add filtering and mapping to *sync* iterables though, like maps and sets.)

> I think the pace at which work is performed is dependent on a few things. 

Unfortunately no. An observable is just a wrapper for a function `f({ next, return, throw })`, so that when you call `observable.subscribe(g)`, it calls `f(g)`. Thus it's totally up to the implementation of `f` when `next()` is called. An observable for directory listings would thus call `readdir` in a loop, continuously calling `next()` when the `readdir` call finishes.

> Then there's backpressure too, which I'm not 100% clear on :-(

An async iterable, on the other hand, consists of an object with a promise-returning `next()` method. The pace at which work is performed on an async iterable can thus be determined by how fast the `next()` method is called---for example, if it is never called, then there is no need to call the next `readdir`. This kind of matching of consumer speed to producer speed, in combination with how it propagates through transforms (like map and filter), is backpressure.

My main concern in opening this is that observable is not misused in places where it is a bad fit. It makes sense for events like "click" where the producer drives the production of events ("push"), but it doesn't make sense for things like directory listings where the consumer drives things ("pull"). I know it is the most-evangelized asynchronous-plural type among the trio of observable, async iterable, and behavior, but I wanted to make sure the right tool is used for the job here instead of the most-evangelized one :)

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/filesystem-api/issues/4#issuecomment-106684461