issue_comments: 610116325
This data as json
| 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/issues/3035#issuecomment-610116325 | https://api.github.com/repos/pydata/xarray/issues/3035 | 610116325 | MDEyOklzc3VlQ29tbWVudDYxMDExNjMyNQ== | 35968931 | 2020-04-07T01:08:24Z | 2020-04-07T06:42:15Z | MEMBER | It should be possible to implement a new backend in xarray now - we've already done it for multiple file formats. However, I suspect that if we completed the project to provide a Flexible API for Storage Backends, then the path to this would become simpler. At the moment each new storage format has to be special-cased within xarray code itself (e.g. zarr), but we want to get to a position where that I/O responsibility is delegated out to other libraries, probably via an entrypoint. Then it would be much easier (and quicker) to develop the necessary interfaces for the formats you mention. |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
458236359 |