mirror of https://github.com/voidlizard/hbs2
157 lines
8.3 KiB
TeX
157 lines
8.3 KiB
TeX
% 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}
|
||
|
||
|
||
|
||
|
||
|