Re: [devel-distro] про API и фронтэнды

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/9/24 22:46, Leonid Krivoshein wrote:
>
> On 10/9/24 12:06, Sergey V Turchin wrote:
>> On Wednesday, 9 October 2024 04:40:37 MSK Leonid Krivoshein wrote:
>>
>> [...]
>>> 1.4. Разве вебовский UI/UX сейчас не приоритетней? Его давно не 
>>> проблема
>>> встраивать в толстые приложения.
>> Проблема. Например, на e2k кроме Gecko/Firefox есть лишь некий 
>> libwebkitgtk4,
>> который не везде встроишь.

Достаточно того, что есть браузер, из него можно конфигурировать систему.


>> Текущий alterator не зависит от жирного web-движка, который резко 
>> поднимает
>> системные требования UI и капризен к аппаратным.
>

Из всего, прошедшего через нас, припоминаю капризы только на mipsel, уже 
нами не поддерживаемом. На нём и правда лагали развесистые веб-движки. 
Мы говорим о десктопных дистрибутивах и встроенном в них конфигураторе. 
Весьма странно ставить такой установщиком с иными требованиями.

Что сейчас очень плохо: различие в функционале ЦУС (acc) и ahttpd (fbi). 
Различия между desktop и web фронтендами. И как ранее было замечено, 
часть будет работать только в среде установщика. Неоправданная 
необходимость умножать затраты на разработку и поддержку.


> Справедливо. Но есть же универсальные декларативщики, начиная с 
> flutter или slint. Наверное, таковых не мало, я в них не разбираюсь, 
> но они точно умеют из одного исходника делать интерфейс и для Web, и 
> для (например) Gtk3/4 или Windows GDI.
>

Откуда вообще взялась необходимость делить фронтенды и придумывать для 
них API? Первоначально автор предполагал возможность появления ещё и 
консольного установщика. Желание иметь только один графический фронтенд 
было, к нему стремились, но не вышло. Не появилось и консольного 
установщика. А раз есть разные компоненты (модули альтератора в виде 
самостоятельных программ или запускаемых скриптов, да ещё и на разных 
языках), требующие интерактивного взаимодействия, то нужен какой-то 
интерфейс между ними, отсюда API woo.

Современный подход также поощряет разделение на бэк и фронт. Большие 
конфигураторы сейчас преобладают в виде веб приложений, это менее 
зависимо от среды рабочего стола и более современно. Среди его 
преимуществ -- нет необходимости тащить графику на сервер, более 
традиционной подход к управлению большой группой машин. Ориентироваться 
на консольный установщик уже поздно в 2024, пусть этот фронтенд 
останется в 80-х.

С единственным фронтендом какой-то обобщённый API становится не нужным. 
Если уж сильно хочется показать два фронтенда, то есть декларативные 
языки, работающие как в десктопном, так и в вебовском окружении.

Организовать работу с единой СУБД -- хранилищем данных конфигурации, для 
каждой стороны проще, чем идти в сторону самоописания API каждого 
модуля. Собственно, модуль и не нужен никому, кроме него самого.

Подписка на изменение каких-то свойств конфигурации через dconf, кроме 
усложнения, имеет ещё два подводных камня. Допустим, мы через 
конфигуратор или dconf-editor поменяли фон рабочего стола и тут же наш 
MATE или Gnome показал это изменение. А теперь то же самое, но через GPO 
на 100500 машин домена. Круто! А что с KDE и Xfce? Нужно адаптеры 
писать? Другой момент: есть изменения, которые нельзя применять, пока не 
будут сделаны все изменения в рамках большой транзакции. Что даст 
подписка подписчику? Может даже поломку системы.


-- 
WBR, Leonid Krivoshein.