#fluid-framework
#жидкий каркас
Вопрос:
Мы протестировали жидкую структуру с минимальными требованиями. В демонстрационном приложении все работает нормально. https://github.com/microsoft/FluidExamples
вопросы:
- Как фреймворк Fluid работает в автономном режиме?
- Наш бэкэнд написан на asp.net ядро. Серверная часть платформы fluid framework написана на node.js . Как интегрировать asp.net базовый серверный сервер с гибкой службой для получения последнего состояния документа? Нужно написать драйвер для гибкой службы?
Ответ №1:
- Не в сети.
Оффлайн — интересная тема для CRDT в целом. Фреймворк Fluid хорошо обрабатывает прерывистые (короткие) автономные сценарии, если у всех подключенных клиентов есть метаданные, необходимые для объединения изменений. Когда пользователь вносит изменения, он делает это в отношении минимального порядкового номера (MinSeq.). Если его автономные изменения будут добавлены к общей трансляции заказов таким образом, что они будут выше MinSeq ее изменений, они будут объединены без дополнительной обработки.
MinSeq заслуживает целого поста, но это порядковый номер, под которым все подключенные клиенты могут собирать метаданные, необходимые для объединения изменений. Поэтому, пока у каждого клиента есть эти метаданные, даже если вы были в автономном режиме, слияние выполняется легко.
Для более длительных автономных сценариев клиент повторного подключения может запросить понизить минимальный интервал (возможно, до последнего минимального интервала автономного клиента). Затем все клиенты будут извлекать операции с момента запроса MinSeq и воссоздавать метаданные. На этом этапе могут быть легко внесены новые изменения, поскольку мы имитировали сценарий, в котором новые изменения превышают минимальный порядковый номер.
Это может вызвать временные проблемы с производительностью и памятью, но не было проблемой в разумных экспериментах. Я не верю, что эта функция в настоящее время реализована в базе кода Fluid Framework, но была разработана, как описано выше. (ПИАР на эту тему был бы очень интересен!)
Для еще более длительных автономных сценариев вам, вероятно, потребуется трехстороннее слияние. Например: два пользователя открывают документ. Пользователь A садится в самолет (теряет интернет) и пишет Macbeth, а пользователь B пишет Pride amp; Prejudice, каково ожидаемое поведение, когда пользователь A присоединяется к сеансу? Это совершенно несовместимые состояния документа, поэтому нам нужно было бы представить пользователям какой-то диалог.
Это не реализовано, но мы обсудили некоторые аспекты эргономики фреймворка при обработке трехстороннего слияния (т. Е. Какие API понадобятся разработчику приложения).
- Текущая жидкость в серверной части, отличной от NodeJS
Состояние документа управляется клиентами и непрозрачно для сервера. В этом выпуске есть аналогичное обсуждение. Самый простой способ получить состояние документа фреймворка Fluid в серверной части .NET — запустить движок JS и открыть документ Fluid. Вы также можете запустить микросервис NodeJS, в котором размещен документ Fluid. Этот сервис будет иметь простую поверхность API, которая позволяет извлекать нужные вам данные.