В рамках разработки индикатора (GUI обертки для CLI демона от яндекса - в подписи) уже неоднократно возникало желание сделать "свою синхронизацию".
У яндекса есть довольно удобный
REST API к диску и тоже вполне юзабельный
WebDav API. И в этих API есть некоторые "плюшки", которые они никак в своего клиента протягивать не хотят (та же очистка корзины).
В очередной раз появившийся интерес начал оформляться во что-то реальное и я решил сформулировать цели и предварительный план этого проекта. Мало ли кто заинтересуется совместной разработкой, да и как обычно - тестеры будут крайне полезны.
И так, к делу:
Глобальная Идея:Создать аналог CLI утилиты/демона yandex-disk в виде библиотеки/класса/отдельного процесса, на Python3, использующего REST API яндекс.диска.
Разработку предполагается вести изначально через
GitHub репозиторий. Проект будет развиваться под OpenSource лицензией.
Ожидаемые бенефиты:
1. Можно сделать индикатор независимым от пропиетарного CLI демона от яндекса (это упросит установку и распространение индикатора и может пригодиться в других проектах)
2. Можно реализовать то, чего нет в демоне от яндекса (например: очистку корзины)
3. "Бесшовная" интеграция с индикатором (упростит обработку ошибок, сделает ненужным оба механизма контроля за состоянием демона: по таймеру и по изменению <y.disk>/.sync/cli.log, однако вместо вотчера за одним файлом потребуется вотчить весь синхронизируемый каталог, но это другая, отдельная задача).
4. Отказ от
уродских неудобных/нестандартных конфигфайлов демона (как вспоминаю конфиги яндексного демна так вновь возникает желание найти разрабов и оторвать им руки
).
5. Возможность создания OpenSorce заменителя пропиетарного CLI демона от яндекса (это - самый сомнительный бенефит, ИМХО, но все же...).
Задачи, которые надо решить:
1. Авторизация приложения по технологии OAuth через сервисы Yandex -
DONE.
2. Решить как будет работать решение:
а. как независимый процесс , причем возможны варианты:
I. запускать отдельное приложение на уровне ОС, коммуникация через socket (+ можно использовать как независимый CLI демон)
II. формировать процесс кодом внутри индикатора, коммуникация ерез pipe (+ можно все запускать в одной программе)
б. как импортируемый/встраиваемый класс, в котром создаются несколько независимых потоков (нужно
понять как потоки будут сочетаться с Gtk.main() циклом.... подозреваю: будут трудно воспроизводимые
глюки.
Предварительно решено делать отдельного клиента с возможностью взять из него класс диска и использовать его независимо в для встраивания в индикатор. 3. Решить вопросы двусторонней синхронизации:
а. синхронизация по изменениям в синхронизируемой папке (инициилизируется по изменениям в каталоге отлавливаемым через intify вотчер) -
IN PROGRES б. синхронизацию по изменениям в облаке (инициализируется по получению
оповещения о изменении на диске) -
требует реализации xmpp клиента с нестандартной авторизацией - пока не понимаю с какой стороны подступиться в. как будут работать обе синхронизации при одновременном возникновении изменений в облаке и в синхронизируемой папке.
- требует изучения в процессе отладки. г. реализовать процедуру полной сверки облака и каталога (
есть нужный запрос в API) и решить - как часто и когда эту "сверку" запускать.
д. продумать модель многопоточной заливки и получения файлов в/из облака -
IN PROGRESS