Comments 14
Т.е. даже архив с полным сезоном какого-нибудь сериала из 20 серий будет
занимать не больше нескольких килобайт (в независимости от качества
видео).
Похоже на торренты.
Похоже на IPFS.
Я бы, впрочем, предложил написать не на С++ (правильно же угадал?), а на каком-нибудь более безопасном языке, чтобы оно легче читалось и поддерживалось. Кстати, а исходники вы из каких-то побуждений не выкладываете на github?
Чтобы выкладывать исходники, нужно их "причесать". Иначе это будет просто куча непонятно чего. Пока руки до этого не дошли.
на каком-нибудь более безопасном языке,
Вообще идеи такие были на Go или Rust переписать. Заодно и потренироваться. Но тут опять нужно время + понимание что же более безопасно.
чтобы оно легче читалось и поддерживалось
C++ более распространен, так что большинству разработчиков его читать и поддерживать проще,
Я правильно понял, что если я отредактирую файл сто раз, у меня будет сто трансформаций вида "Удалить file1.txt Добавить file1.txt" и на сервере будет храниться сто самостоятельных версий file1.txt? Но при этом, если я захочу восстановить версию 99й итерации, я не могу её просто скачать, а мне нужно будет сначала последовательно добавить-удалить предыдущие 98?
Если в результате редактирований файл будет иметь 100 разных содержимых, то да, на сервере будет 100 файлов. ,Что вполне понятно: если у вас 100 разных файлов и вы хотите иметь возможность получить любой из них, то все они должны хранится на сервере.
если я захочу восстановить версию 99й итерации
Нет. Трансформации выполняются в памяти и скачивается только итоговый вариант файла.
Т.е. у вас 100 разных файлов и 100 трансформаций (200 команд =100 удалений + 100 добавлений). Трансформации будут выполнены, будет определено что нужен файл № 100 и скачен будет только он. Все остальные 99 файлов скачиваться не будут. Потому что это файл с одним и тем же именем. И в проекте он будет только один. А значит нет смысла качать 99 его исторических копий, которые нам не нужны.
Нет. Трансформации выполняются в памяти и скачивается только итоговый вариант файла. <...>
А значит нет смысла качать 99 его исторических копий, которые нам не нужны.
Тогда следующий абзац ввёл меня в заблуждение.
Для получения нужного состояния клиенту необходимо скачать все трансформации, предшествовавшие этому состоянию, и выполнить их у себя.
Понял. Да, сами трансформации придется качать все. Иначе не ясно какой файл в последней итерации.
У меня было два варианта:
Хранить все состояния в каждой трансформации
Хранить в трансформации только изменения
Я выбрал вариант № 2 потому что в 1-ом слишком много избыточных данных. А так как размер самих трансформаций небольшой (+они кэшируются в папке проекта), то скорость не падает.
ХЕШ файла = хеш (SHA-3+crc32) данных файла + размер файла
Удивительное сочетание алгоритмов! Если у вас уже есть криптостойкая контрольная сумма, зачем добавлять к ней CRC-32? Кстати, а почему SHA-3?
Берем абсурдную идею и находим ей применение