mirror of https://github.com/voidlizard/hbs2
50 lines
2.5 KiB
Plaintext
50 lines
2.5 KiB
Plaintext
TODO: expose-all-new-rpc
|
||
Вытащиь все новые RPC в библиотеку,
|
||
так как нам нужны RefLogAPI и PeerAPI в клиенте
|
||
|
||
TODO: detect-new-rpc-on-first-run
|
||
первый раз при запуске пытаться обнаружить
|
||
новый RPC если он не указан в конфиге.
|
||
Предлагать записать его в конфиг (или просто писать его в конфиг?).
|
||
|
||
TODO: local-config
|
||
Смержить или заново сделать. Что бы конфиг брался из локального
|
||
каталога.
|
||
|
||
При генерации так же обновлять cookie для конфига. Таким образом,
|
||
cookie станет идентификатором проекта, когда state станет
|
||
общим для всех refs (скоро).
|
||
|
||
TODO: save-objects-via-new-rpc
|
||
Сохранять объекты через новый RPC. Удалить всё,
|
||
что связано со старыми способами (HTTP, CLI)
|
||
|
||
TODO: update-ref-via-new-rpc
|
||
обновлять ссылку через новый RPC.
|
||
|
||
TODO: git-group-key
|
||
Указывать для ссылки (возможно, для git remote?)
|
||
Перегенерировать, если ключ изменился.
|
||
|
||
Кейс: изменения "в прошлом". Сейчас репо это сумма всех
|
||
"логов", каждый "лог" - U(объектов из операции git push + установка ссылки).
|
||
|
||
Соответственно, перегенерировать ключ **обязательно**, если
|
||
авторы удалены из ключа.
|
||
|
||
Если ключ перегенерировать время от времени, как планировалось,
|
||
то возможна ситуация, когда нового автора в **старых** ключах
|
||
не будет. И у него не будет доступа к каким-то "старым"
|
||
объектам. А, в отличие от других примений, они ему нужны.
|
||
|
||
Что делать?
|
||
|
||
Даже если сгенерировать на каждый лог, где этот автор
|
||
отсутствовал --- групповой ключ, то ссылка на него не будет
|
||
доступна в старых сегмента, и при скачивании блоков,
|
||
hbs2-git не будет знать, какой ключ использовать.
|
||
|
||
|
||
|
||
|