html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/pull/2287#issuecomment-405293927,https://api.github.com/repos/pydata/xarray/issues/2287,405293927,MDEyOklzc3VlQ29tbWVudDQwNTI5MzkyNw==,2089799,2018-07-16T15:50:48Z,2018-07-16T16:10:09Z,NONE,"> if xarray's rasterio backend wouldn't be a better template for an imageio backend instead. 

I started with `rasterio` in the beginning, since TIFF-like containers are not modifiable, `cache` is crucial. However, it is my understanding, and please correct me if I am wrong, that `rasterio` backend is aimed at being a [read-only I/O](https://github.com/mapbox/rasterio/issues/576) for `xarray` without having the extensibility for write ability, and I'm really eager to keep the ability to aggregate multiple files through `dask`, as well as saving data through `imageio` transparently (if plausible) :p

On second thought, maybe `open_rasterio` type of approach with `to_zarr` for saving is more preferable? But what are the possible approaches for `open_mfdataset` (and the potential of using `dask` for out-of-memory file I/O)? 

> For example, can imageio open any file which resembles a Dataset (i.e.: more than one variable with different datatypes), or would a DataArray be enough?

Generally, image containers opened by `imageio` represents a single `Dataset` only, which is why I default names to their readout sequences. However, there are indeed cases where multiple variables exist, such as pyramids of image sequences, each pyramid layer represents a different resolution for the sequence. 

I must admit that a single `DataArray` is more applicable to the general usage.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,341321742