From 9cde97cb055bfdccc1d0a85b8238f13981268dbe Mon Sep 17 00:00:00 2001
From: Dmitry Zuikov <dzuikov@gmail.com>
Date: Sat, 23 Mar 2024 05:34:47 +0300
Subject: [PATCH] wip

---
 docs/papers/hbs2-browser/design.tex   | 18 ++++++
 docs/papers/hbs2-browser/usecases.tex | 93 +++++++++++++++++++++++++--
 2 files changed, 105 insertions(+), 6 deletions(-)

diff --git a/docs/papers/hbs2-browser/design.tex b/docs/papers/hbs2-browser/design.tex
index 35566fb4..9ba65525 100644
--- a/docs/papers/hbs2-browser/design.tex
+++ b/docs/papers/hbs2-browser/design.tex
@@ -2,6 +2,24 @@
 
 \chapter{Дизайн}
 
+
+Итак, \term{hbs2-browser}{hb2-browser} это компонент, который позволяет
+просматривать некие метаданные, сохраненные в \term{ref}{ссылках}, видимо,
+типа \term{refchan}{рефчан}.
+
+Почему refchan:
+
+\begin{enumerate}
+  \item Требуется несколько авторов, т.е агентов,
+        которые будут публиковать данные;
+  \item Требуется при этом исключить компрометацию всей
+        системы при компрометации какого-то одного приватного ключа <<автора>>;
+  \item Требуется возможность валидации;
+  \item Требуется проверка ACL;
+  \item Требуется включение/исключение авторов.
+\end{enumerate}
+
+
 % \section{Структуры данных и протоколы}
 
 % \subsection*{Предпосылки}
diff --git a/docs/papers/hbs2-browser/usecases.tex b/docs/papers/hbs2-browser/usecases.tex
index 7f8f6d54..b278d06f 100644
--- a/docs/papers/hbs2-browser/usecases.tex
+++ b/docs/papers/hbs2-browser/usecases.tex
@@ -135,20 +135,101 @@ L2. L2 подразумевает более подробную информац
 
 \subsubsection{Собственный EDSL}
 
-Требуется значительное время для разработки, необходим тулинг,
-высокий порог входа, возможное недовольство пользователей.
+Требуется значительное время для разработки, необходима разработка
+средств разработки и отладки, высокий порог входа, возможное
+недовольство пользователей.
 
 
 \subsubsection{Биндинги в скриптовые ЯП + хост}
 
 Достаточно затратное встраивание, вопрос, какие именно ЯП выбрать из
-большого списка.
+большого списка, необходимость принять множество решений при
+отсутствии достаточного количества объективных факторов для их оценки
+(какой язык <<лучше>>, какой <<хуже>> и множество еще)
 
-\subsubsection{Внешний процесс + IPC}
+\subsubsection{Внешний процесс + некий IPC}
 
-\subsubsection{Внешний процесс + RPC}
+К недостаткам относятся: необходимость в управлении этим процессом и
+его артефактами (сокеты, named pipes).
+
+
+Тем не менее, данный способ видится наиболее универсальным и простым
+относительно прочих.
+
+Способ в каком-то роде давно проверенный и доказанный: и cgi и fastcgi
+работают десятилетия уже, подход масштабируется.
+
+Внешним процессом может быть как некий сервер/сервант, так и
+запускаемый нашим процессом внешний процесс, обеспечивающий
+коммуникацию через pipe.
+
+При реализации Messaging через пайпы мы получаем такой же абсолютно
+RPC+Notifications, как во всех прочих частях системы: UDP, TCP, Unix
+sockets.
+
+Протокол может быть и бинарным и текстовым. Текстовый протокол может
+видеться, примерно похожим на HTTP:  <<запросом>> является подобный
+HTTP заголовок, далее пустая строка <<\texttt{CR LF CR LF}>>, далее
+тело ответа, например, в JSON.
+
+Заголовки могут быть урезанным набором заголовков HTTP.
+
+При таком подходе мы можем интегрировать процессы, написанные на
+других языках, они получают достаточно простой текстовый интерфейс,
+при условии, что у них нет удобной реализации CBOR.
+
+Начать же мы можем с того, что просто реализуем \texttt{Messaging} c
+фреймингом, аналогичный TCP/ByPass --- но для pipes.
+
+Этот протокол может быть и синхронным и асинхронным, вероятно, лучше
+сразу же делать его асинхронным --- т.е потоки запросов и ответов
+являются независимыми, а на какой конкретно запрос поступает ответ ---
+зависит от специального поля в заголовке \texttt{REQID}.
+
+При асинхронном подходе нам не обязательно балансировать нагрузку
+внутри нашего хост-приложения --- балансировать может сам запущенный
+процесс.
+
+Почему нужно делать именно так: fork+RPC через pipes.
+
+\begin{enumerate}
+  \item Имея механизм RPC через потоки ввода--вывода мы можем этот же
+  механизм задействовать для named~pipes, то есть, для взаимодействия
+  с внешним процессом, которым мы не управляем.
+  \item Мы можем управлять нужным процессом и запускать его
+  самостоятельно, не полагаясь на всякие системные вещи, типа systemd
+  и внешних конфигурационных скриптов, снижая количество внешних
+  факторов, влияющих на функционирование системы.
+  \item Мы можем балансировать нагрузку, запуская нужное нам
+  количество процессов и распределяя нагрузку между ними, если они
+  имеют свойство блокироваться.
+\end{enumerate}
+
+Почему бинарный протокол в первую очередь:
+
+\begin{enumerate}
+  \item Текстовый можно сделать позднее, для этого нужно просто
+  подменить encode/decode в определении протокола.
+  \item Это самое простое по реализации решение в данный момент, и
+  отработанное на примере других протоколов/других транспортов.
+  \item У нас всё уже для этого есть, и с примерами для других видов
+  транспорта. Протокол для pipes будет почти полностью аналогичен
+  протоколу для Unix sockets.
+  \item Автор является и основным разработчиком системы, маловероятно,
+  что на текущем этапе появятся какие-то другие разработчики, которые
+  будут заинтересованы в разработке на других ЯП, кроме Haskell, а раз
+  так, то все просто могут взять библиотеку и писать эти модули на
+  Haskell.
+\end{enumerate}
+
+Почему асинхронный протокол:
+
+Потому, что синхронный --- его частный случай, как если бы асинхронный
+процесс просто затыкался после одного запроса. Это всё равно та
+ситуация, которую надо уметь обрабатывать. Так что сделав асинхронную
+обработку --- мы получим синхронную бесплатно. Механизмы ServiceProto
+уже умеют делать синхронные вызовы для асинхронных протоколов.
 
-\subsubsection{Внешний процесс + HTTP}