-
Notifications
You must be signed in to change notification settings - Fork 104
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
where shall parameters get stored? #210
Comments
payload currently uses byte0 with values 0x00, 0x01, 0x02 (to give key/enc type). this should be recognized also in future for backwards compatibility (but always write new flexible format, so old format can be dropped at some time in the future). first idea (superceded by msgpack, see comment below) for new flexible format for parameter record:
So, we have 3 bytes more to store, but gain flexibility for the future. Also the code gets simpler than in PR #207. As we have 256 values for compression, we could even map some parameters directly, e.g. use 0-9 for gzip+level, 10-19 for lzma+level, etc. (alternatively: use 1 byte more for compression params). |
Some measurements with PR #207 code - all tests on local SSD filesystems: --compression=6 --mac=0 (zlib default level 6 + sha256) --compression=6 --mac=1 ("" + sha512-256) --compression=1 --mac=1 (fastest zlib compression + "") --compression=0 --mac=1 (no compression + "") |
I changed the 0x03 format again to use msgpack to get more flexibility and easier code. |
As already seen in PR #207 and issue #209 there is some need for more per-repository and/or per-payload parameter storage:
Currently, there seem to be 2 places where such information can be stored:
While some stuff could be defined once and be global per repository, it might be more flexible to have it in each payload, so you can switch to new stuff without having to start a new repo.
But: one byte is not enough to represent all we need.
The text was updated successfully, but these errors were encountered: