From 70d52e32df80e0c364579d6c839ad4c85e95fcce Mon Sep 17 00:00:00 2001 From: Dmitry Zuikov Date: Fri, 22 Mar 2024 09:59:10 +0300 Subject: [PATCH] wip --- docs/papers/hbs2-browser/Makefile | 2 +- docs/papers/hbs2-browser/design.tex | 28 ++++ docs/papers/hbs2-browser/hbs2-browser.tex | 4 +- docs/papers/hbs2-browser/usecases.tex | 156 ++++++++++++++++++++++ 4 files changed, 188 insertions(+), 2 deletions(-) create mode 100644 docs/papers/hbs2-browser/design.tex create mode 100644 docs/papers/hbs2-browser/usecases.tex diff --git a/docs/papers/hbs2-browser/Makefile b/docs/papers/hbs2-browser/Makefile index 2c40d062..a8387b08 100644 --- a/docs/papers/hbs2-browser/Makefile +++ b/docs/papers/hbs2-browser/Makefile @@ -1,6 +1,6 @@ REV:=$(shell git rev-parse --short HEAD) -CHAPTERS:=intro.tex +CHAPTERS:=intro.tex usecases.tex design.tex define make_target $(basename $(1))-$(REV)$(suffix $(1)) diff --git a/docs/papers/hbs2-browser/design.tex b/docs/papers/hbs2-browser/design.tex new file mode 100644 index 00000000..35566fb4 --- /dev/null +++ b/docs/papers/hbs2-browser/design.tex @@ -0,0 +1,28 @@ +% vim: set textwidth=70: + +\chapter{Дизайн} + +% \section{Структуры данных и протоколы} + +% \subsection*{Предпосылки} + +% \subsection*{Возможное византийское поведение узлов} + +% \begin{description} +% \end{description} +% \subsubsection*{Сообщение фактически неверных данных} + +% \subsubsection*{Флуд} + + +% \section{Стейт} + +% Дизайн стейта строится из следующих предпосылок: + +% \paragraph{Жопа} +% \paragraph{Кита} +% \paragraph{Печень} +% \paragraph{Трески} + + + diff --git a/docs/papers/hbs2-browser/hbs2-browser.tex b/docs/papers/hbs2-browser/hbs2-browser.tex index 41afb471..94fd7e53 100644 --- a/docs/papers/hbs2-browser/hbs2-browser.tex +++ b/docs/papers/hbs2-browser/hbs2-browser.tex @@ -90,7 +90,9 @@ \maketitle \tableofcontents -\include{intro} +\include{intro.tex} +\include{usecases.tex} +\include{design.tex} \end{document} diff --git a/docs/papers/hbs2-browser/usecases.tex b/docs/papers/hbs2-browser/usecases.tex new file mode 100644 index 00000000..7f8f6d54 --- /dev/null +++ b/docs/papers/hbs2-browser/usecases.tex @@ -0,0 +1,156 @@ +% vim: set textwidth=64: + +\chapter{Сценарии} + +\section{Оракул} + +\subsubsection{Публикация <<фактов>>} + +Оракул стартует и обновляет стейт. + +Затем публикует набор <<фактов>>, отсутствующих в известном ему +состоянии. + + +\section{hbs2-browser} + +\subsection{Отображение списка ссылок} + +Предполагается, что \term{hbs2-browser}{hbs2-browser} будет отображать +ссылки в виде списка с бесконечным скроллом, с возможностью поиска, с +неким языком запросов. + +Для начала поисковой строкой будет являться просто подстрока из самой +ссылки. В дальнейшем возможно расширение при помощи некоего DSL, где +будут перечислены атрибуты. + +Если будут какие-либо специфические формы, с выбором опций --- то +предпогается, что они просто будут добавлять некие термы в эту строку. + +На верхнем уровне отображется базовая информация для ссылки: её +текстовое представление (обычно публичный ключ в base58), её тип. + +Возможно, некое описание. Например, название репозитория и список +хэштегов. + +Предполагается оторбражение ссылок в порядке некоего веса, который +вычисляется (TBD), возможно, формула для вычисление веса так или +иначе определяется пользователем, например, возможностью +редактирования весовых коэффициентов. + +Например, факторами могут быть время обновления и отношение к +пользователю, которое может вычисляться исходя из встречаемости +его ключей в данных ссылки (как пример). + +Данное требование предполагает наличие обязательных и дополнительных +полей у отображаемой ссылки. + + +\subsection{Отображение детализации ссылки} + +Понятно, что ссылок может быть произвольное количество и hbs2-browser +не в состоянии знать их все, а тем более, осуществлять какую-то работу +с ними. У нас не стоит цели разработать и запустить универсальную CMS. + +Мы не сможем встроить функции работы, например, с проектами в git в +сам браузер, и вероятно, это было бы слишком. + +hbs2-browser может предоставить некоторый каркас отображения +метаинформации; возможно несколько уровней. И предоставить возможность +перенаправления на приложение, которое умеет работать со ссылкой +(данными) такого типа. + +Рассмотрим примеры. + +\paragraph{git} Мы бы хотели видеть: название и описание репозитория, +список авторов, README если есть, список бранчей и тегов. + +Еще бы мы хотели видеть структуру каталогов, и в переспективе --- +просматривать каждый файл, как в онлайн-редакторе, так и raw виде. + +Однако, непонятно, как это сделать. Проекты могут иметь огромные +размеры, как по количеству файлов, так и количеству коммитов. + +Если всё это делать метаданными, то размер метаданных сравняется +или превысит размер изначальных данных, которые тоже могут +иметь миллионы записей и гигабайты/десятки гигабайт размеров +в предельных случаях (монорепозитории). + +Распаковка объектов на лету тоже малоприменима --- git~object~packs +могут быть огромными, их может быть много, без полной распаковки +объект не извлечь. + +Вероятно, на первом этапе стоит ограничиться списком ссылок и +детализацией информации ссылки, например, нескольких уровней -- L1, +L2. L2 подразумевает более подробную информацию о какой-то сущности +ссылки, поэтому параметризуется этой сущностью. + +\paragraph{Пример:} + +\begin{verbatim} + L1:репозиторий + -> L2:список автров + -> L3:автор +\end{verbatim} + +С другой стороны, можно представить и таким образом: + +\begin{verbatim} + L1:репозиторий + -> L2:список авторов + -> L2:автор +\end{verbatim} + + +Видно, что задача очень хорошо бы ложилась на XML/XSLT, если бы у нас +была подобная опция. К сожалению, в современном мире такой опции нет +и нам придётся изобретать некую замену, которая будет делать тоже +самое, но не так. + + +Таким образом, нам необходим способ преобразования из модели +<<фактов>> в отображаемый формат (html). + +Мы не хотим, что бы этот способ был привязан к какому-то конкретному +языку программирования. + +Мы не хотим, по возможности, встраивать эти преобразования в +\term{hbs2-browser}{hbs2-browser}. + + +Рассмотрим возможные варианты задания преобразований: + +\subsubsection{SQL+JSON} + +Пользователь задаёт в конфигурации SQL стейтмент, порождающий JSON + +шаблон, который преобразует JSON в формат для отображения (html/htmx). + +Достаточно просто, доступный многим стек, возможны сложности с +выполнением отображения в случае, если одного SQL запроса +недостаточно, фиксируем СУБД (скорее всего, это будет sqlite, но это +деталь реализации, которую не хотелось бы раскрывать), сколько-нибудь +сложную логику писать в СУБД достаточно проблематично и способ зависит +от БД. Отсутствие нормальной типизации. Слабые возможности абстракции. + + +\subsubsection{Собственный EDSL} + +Требуется значительное время для разработки, необходим тулинг, +высокий порог входа, возможное недовольство пользователей. + + +\subsubsection{Биндинги в скриптовые ЯП + хост} + +Достаточно затратное встраивание, вопрос, какие именно ЯП выбрать из +большого списка. + +\subsubsection{Внешний процесс + IPC} + +\subsubsection{Внешний процесс + RPC} + +\subsubsection{Внешний процесс + HTTP} + + + + +