2012-10-06 1 views
13

Мы знаем, что клиенты рабочего стола Dropbox используют алгоритм двоичного разложения, чтобы разбивать все файлы на блоки и загружать только блоки, которые он еще не имеет в облаке (https://serverfault.com/questions/52861/how-does-dropbox-version-upload-large-files).Дифференциальные/инкрементные загрузки Dropbox с использованием REST API

Тем не менее, API Dropbox, насколько я вижу, может загружать только весь файл (/files_put, /files (POST)), когда требуется синхронизация.

Есть ли способ сделать дифференциальную/инкрементную синхронизацию с помощью Dropbox API, т. Е. Загрузить только измененную часть файла, такую ​​как клиенты на рабочем столе?

Если это невозможно, то каковы наилучшие методы для периодической синхронизации больших файлов с небольшими изменениями с помощью Dropbox API?

+0

Отличный вопрос - вы когда-нибудь находили ответ? – DoctorG

+0

К сожалению, нет. Я вернусь к этому сообщению, если найду что-нибудь актуальное. –

+0

AFAIK, вы можете скачивать файлы по блокам с помощью запроса поиска диапазона HTTP (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2) API-интерфейс Dropbox HTTP поддерживает его (по крайней мере, для загрузки файлы), не уверены в загрузке. Подробнее о методе/файлах (GET): https://www.dropbox.com/developers/core/docs –

ответ

4

К сожалению, это невозможно, и я подозреваю, что он никогда не будет доступен.

После небольшого исследования я нашел запрос функции for delta-syncing to be integrated into the API. Dropbox не ответил, и сообщество не поддержало этот запрос.

Я бы предположил, что причина, по которой Dropbox не предоставила эту функциональность, и, вероятно, никогда не будет, заключается в том, что это опасная функция в руках неизвестных разработчиков.

Рассмотрите случай, когда вы пишете приложение, использующее такую ​​систему обновления смены треугольника для обновления больших файлов. Вы тщательно тестируете свое приложение и публикуете его в магазине приложений. Через пару недель после вашего первоначального выпуска и многочисленных загрузок вы начинаете получать плохие отзывы и жалобы, потому что вам удалось пропустить очень конкретный тестовый пример.

В этом конкретном, ошибочном случае вы просчитали дифференциальное смещение на 1 байт. о нет! Вы уже испортили тысячи файлов, для сотен пользователей!

Учитывая такую ​​возможность, я думаю, что лично попрошу Dropbox НИКОГДА не предоставлять такую ​​функцию dev. Если бы они интегрировали такую ​​функцию в API, они нарушали бы свою цель №1, чтобы обеспечить надежные надежные облачные резервные копии важных файлов с надежными облачными &.

+3

Я не согласен с вашим заключением: возможность совершать ошибки не должна быть причиной не для того, чтобы обеспечивают такую ​​функциональность. Вы не можете (и не должны) присматривать за разработчиками. Пока вы не делаете вещи опасными по назначению и предоставляете хорошие предупреждения и остатки, когда что-то может быть опасно, я не вижу проблемы с предоставлением чего-то подобного. –

Смежные вопросы