You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The zip crate isn’t really designed around e.g. accessing things over the network, and it shows in issues like zip-rs/zip2#231. TBF, that issue is fixed, but the zip crate is still designed around sync filesystem abstractions.
Feel free to close this if zip-over-network isn’t in-scope for zarrs_zip!
So far I’ve toyed around with
rc-zip{-tokio,-sync}, which currently only does reading, but has the nicest API, so if it ever gains write support, that’s probably the one
async_zip, which seems to work fine over the network, but I didn’t benchmark if it’s doing things smartly
The text was updated successfully, but these errors were encountered:
Yes, this would be great @flying-sheep! async support has been a longstanding gap for the zip store. Both crates look like reasonable choices, and I'm not bothered about the first option being read-only. Writing to zip stores is a bit of a foot gun anyway since chunks cannot be amended.
The
zip
crate isn’t really designed around e.g. accessing things over the network, and it shows in issues like zip-rs/zip2#231. TBF, that issue is fixed, but thezip
crate is still designed around sync filesystem abstractions.Feel free to close this if zip-over-network isn’t in-scope for
zarrs_zip
!So far I’ve toyed around with
rc-zip{-tokio,-sync}
, which currently only does reading, but has the nicest API, so if it ever gains write support, that’s probably the oneasync_zip
, which seems to work fine over the network, but I didn’t benchmark if it’s doing things smartlyThe text was updated successfully, but these errors were encountered: