-
Notifications
You must be signed in to change notification settings - Fork 62
RFC 9 comment 4 #406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
RFC 9 comment 4 #406
Conversation
Automated Review URLs |
|
|
||
| > 1. The ZIP64 format extension SHOULD be used, irrespective of the ZIP file size. | ||
|
|
||
| I'm not familiar enough with ZIP to understand the rationale for this recommendation or how straightforward it would be to follow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ZIP without ZIP64 has relatively low limits compared to how Zarr is commonly used in practice.
ZIP64 is an extension to the standard ZIP file format that removes limitations on file and archive size, allowing for files over 4GB and archives with more than 65,535 files
Appending to a ZIP file that does not use ZIP64, might require that the entire ZIP file be rewritten if these limits are to be exceeded.
My current expectation is that there will need to be significant work on zip file implementations in standard libraries in order to take full advantage of this specification. While not wanting to take on additional dependencies may be a valid reason for not following the recommendation, I think there are valid reasons for continuing to strongly recommend its use.
As far as I can see, there is not explicit space for implementation guidance in the specification. This seems like it would be a good accessory document to have though.
| > Similarly, some operating systems expect an image to be stored in a single file, as apparent by e.g. file permission systems, file type concepts (e.g. file name extensions) and file type-dependent functionality (e.g., double/right-click, drag-and-drop, preview). | ||
|
|
||
| The 'preview' aspect makes it tempting to want to embed a thumbnail, which could be supported by some applications or operating system plugins. | ||
| Should this be explicitly forbidden / discouraged / encouraged in a standard way? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not clear to me that a thumbnail would be specific to the single zip file case. If this is a desired feature, I would suggest proposing a standard for all OME-Zarr images.
No description provided.