anytype-heart/docs/store.md

Store

Должна быть некоторая структура, которая будет хранить состояние приложения, а именно:

1. Какие документы/блоки с какими версиями сохранены.
2. Какие экраны были открыты в последний раз, какие окна.
3. Все настройки клиента, которые не сохраняются в IPFS, должны быть в этой структуре состояния.
4. В каких поля ввода что содержится.

Когда Middleware штатно/аварийно завершает своё выполнение, при следующем запуске состояние должно восстанавливаться из этого файла.

Раз в несколько секунд middle записывает своё состояние в этот файл.

Наверное, плохая идея: store описан в .proto, клиент имеет к нему доступ

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

Получится-ли сходу реализовать соответствие files <--> documents/blocks

А что, если вот так:

1. Есть центральная директория /Anytype, в которой лежат папки документов – на каждый документ по папке.
2. В папке документа лежат файлы – по файлу на каждый блок. Если у документа есть внутренние документы, то там же, соответственно, лежат соответствующие им папки. Плюс лежит .json файл, который содержит структурную информацию документа. Тоже типа такой блок.
3. В папке лежит .git папка, в которой содержится история версий.

Так вот, пишем watcher, который следит за изменениями как внутри файловой системы в директории /Anytype, так и за изменениями, сделанными в приложени Anytype, и автоматически коммитит изменения, меняет файлы.

То есть, например, скидываем картинки в папку /Anytype/kitties, и автоматом все юзеры, кто работает с этим документом, получают новые блоки с картинками.

Текстовые файлы, например, хранятся в виде markdown файлов. Информация о том, как отображать картинку, может хранится в meta-блоке изображения.

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

Как это заимплементить, MVP

Документ состоит только из текстовых блоков. Блоки и документ – каждый имеет свою историю версий. Есть чейн изменений блока, и есть его скомпилированный стейт. Скомпилированный стейт – .md файл. Чейн изменений – файлы в специальной директории.

Или так – блоки и документы хранятся на одном уровне иерархии, а в папке документа хранятся ссылки на эти блоки/файлы.

Есть директория /anytype. CLI-клиент, в котором есть команды:

    block_create() -> docId
    block_set(id, 'text')
    block_remove(id)

    doc_create() -> docId
    doc_addBlock(docId, id, prior)
    doc_setPrior(docId, id, prior)
    doc_removeBlock(docId, id)

Есть watcher. Это JS-скрипт, который чекает изменения файлов в папке.