Cutting Corners - TrueLink/Carpona GitHub Wiki

(заметки по реализации)

Хочется, чтобы оно было более-менее развиваемо из самого себя с самого начала Для этого с самого начала допускаем внешние one-shot воркеры и бинарники. Это отличается от jupyter, так как там кернел торчит живой все время жизни ноутбука, там это скорее agent чем воркер.

Стабильность бинарников можно сделать какой-то автопроверкой на другой машинке То есть "импорт бинарников" а не просто "запустить команду", чтобы деплоилось оно всегда через рантайм.

Маркировать все "агенты/воркеры с сайд-эффектами" чтобы они отличались от "чистых воркеров"

Хранилище - считаем, что у нас индексы в RAM, плюс распределенные а-ля TreeMerge (+пул нового по которому мы ищем всегда)

Синк - обмен фактами, дерево контекстов per-device с ручным мержем пока что.

Мутабельные обьекты мержаются как и раньше через tree-merge, это грубо говоря кэш. Считаем, что это разновидность вьюшки, отдельно идут факты "правка дефинишна вьюшки", а синхронизация "какой факт в каком неймспейсе

Multi-tenancy сейчас не делаем, делаем один инстанс на юзера.
То есть spawn новых инстансов методом копирования, человек сто сервис выдержит
С аутентификацией и апдейтами все сложно и непонятно ((

Структура БД

Json fact store. Содержит факты, пространства имён (внутри пространства имен факты никак не организованы)

Вьюшки (фильтры, индексы, то-се). Имеют на входе одно или больше пространств имён, результаты поиска создают новое пространство имён.

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

Не забыть различать локальные и глобальные пространства имён

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

Таким образом, у факта есть содержимое, то, в каких неймспейсах он находится, трейс откуда он произошел.

Мутабельные обьекты нужны для отображения состояния сущностей/систем которые живут продолжительное время и изменяются на протяжении этого времени.

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

Сессии аналогично ссылаются на обьект+ревизию, чтобы мы могли посмотреть как на историческое состояние обьекта, так и на его снапшот в момент добавления.

факты и пространства имен имеют ID, которые в свою очередь имеют названия (captions). один идентификатор может иметь много названий, одно название скорее всего ведет на много идентификаторов.