wip

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))

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{Трески}
+
+
+

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}
 

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}
+
+
+
+
+