[devel-distro] про API и фронтэнды
Leonid Krivoshein
klark.devel at gmail.com
Thu Oct 10 22:29:00 MSK 2024
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.
More information about the devel-distro
mailing list