Если бы дизайнером D-Bus был я...

[vitus_wagner]

Общесистемная/общесессионная шина сообщений, по которой приложения могут общаться между собой - штука полезная.
К сожалению, существующий кандидат на роль такой шины - D-Bus обладает рядом недостатков, затрудняющих понимание и использование её авторами приложений, и делающих практически невозможным использование этой технологии пользователями, обустраивающими свою рабочую среду с помощью наколенных скриптов.

Я бы сделал немножко по-другому


Как принято в Unix, все есть файл. Поэтому шина сообщений с точки зрения программы представляет собой двунаправленный файловый дескриптор (например, сокет) куда посылаются сообщения и откуда они принимаются.

Шина имеет топологию "звезда" - есть некий процесс - менеджер шины, с которым соединяются все процессы, желающие по этой шине общаться, и который решает кому какие сообщения форвардить.

Каждый из процессов, пользующихся шиной идентифицируется уникальным именем. Имя имеет иерархическую структуру (somethig.something.else).

Имена бывают двух видов - уникальные, генерируемые менеджером шины в момент соединения клиента (uuid.ХХХХХХХ где XXXXХХ некая алфовитно-цифровая строка) и well-known, к которым можно обращаться, чтобы получить некий известный сервис.

Вообще говоря, если менеджер шины знает, что процесса, предоставляющего данный сервис в данный момент в системе/сессии нет, он имеет право этот процесс запустить, если знает как.

Сообщения представляют собой текстовые строки, завершающиеся символом newline. Синтаксис может быть любым - лисповские S-expression, Tcl-списки, аналог командной строки shell. Мне представляется наиболее разумным использование синтаксиса shell.
Во-первых, этот синтаксис наиболее понятен всем пользователям. Во-вторых, shell таки самый высокоуровневый из распространенных скриптовых языков, Парсить сообщение в таком синтаксисе в шелл-скрипте можно посредством

read message
set -- $message

Естественно, никакой типизации. Все есть строка. А как эту строку интерпретировать - вопрос договоренности между клиентом и сервисом (опубликовнаного интерфейса). Причем на уровне семантики, а не синтаксиса.

Формат сообщения следующий

отправитель:получатель параметры

Если в качестве получателя указана звездочка, то это широковещательное сообщение, которое рассылается всем клиентам (если только они не попросили менеджер шины фильтровать широковещательные сообщения и данное сообщение под фильтр не попало.

Если клиент отправлеят менеджеру шины сообщение, не содержащее адреса отправителя, то менеджер, прежде чем отправить сообщение получателю подставляет туда уникальное имя клиента, присвоенное ему при соединении.

При коннекте к менеджеру клиент получает от него сообщение

manager.Hello:uuid.XXXXXXX

т.е. клиенту сообщается какое уникальное имя ему присвоили.

Если клиент хочет зарегистрировать well-known имя, он посылает сообщение:

manager.RegisterName имя

на которое может получить либо

manager.RegisterName:имя ok

либо

manager.RegisterName:имя error "имя уже занято"

После успешной регистрации имени, все имена в иереархическом дереве имен, начинающиеся с этого имени, считаются принадлежащими данному клиенту.

Сообщения с конкретным получателем могут быть вызовами методов, или ответами на вызов. У ответа на вызов получателем, как правило, является uuid.XXXX (исключение см выше).

Любой клиент, зарегистрировавший имя должен поддерживать метод Help, который вызывается следующими способами

some.client.Help

Возвращает текстовое описание того, что этот клиент делает (apropos)

some.client.Help objects

Возвращает список вложенных объектов в данном поддереве имен, которые поддерживаются данным клиентом.

some.client.Help methods
some.client.subobject.Help methods

Возвращает список методов, которые можно вызывать

some.client.Help parameters Имя

Возвращает список параметров указанного метода

some.client.Help retval Имя

Возвращает информацию о том, что данный метод возвращает

some.client.Help errors Имя

Список ошибок, которые может вернуть данный метод.


Сообщение, являющееся ответом на вызов метода выглядит как

some.client.Method:uuid.caller ok возвращаемые значения

или

some.client.Method:uuid.caller error сообщение об ошибке [машинно-читаемые данные об ошибке]

Методы объекта manager (менеджера шины)
Hello (вызывается неявно при соединении)
RegisterName (см выше)
UnregisterName - отмена регистрации имени (при закрытии соединеия отменяются все имена, зарегистрированные данным клиентом)
Filter glob-patterns - установка фильтра на широковещательные сообщения. Шаблон предваренный восклицательным знаком означает "не посылать сообщения удовлетворяющей данному шаблону". Просто шаблон - "посылать только сообщения, удовлетворяющие данному шаблону".
Client имя - возвращает известную менеджеру информацию об указанном клиенте. По крайней мере пользователя-владельца соответствующего процесса.
Available имя - возвращает статус доступности указанного имени. Может быть либо active (процесс, зарегистрировавший такое имя, выполняется) startable - менеджер знает, как такой процесс запустить и unknown.
Monitor on/off- заправшивает/отменяет пересылку данному клиенту ВСЕХ сообщений, бегающих по шине, независимо от отправителя получателя.
Debug on/off - разрешает данному клиенту посылать сообщения от имени любого отправителя. Этот метод завершается успешно только если юзер-владелец клиента совпадает с юзером-владельцем процесса-менеджера.

Некоторые соглашения о пространстве имен:

hw.* такие имена должны использовать в качестве имен отправителей сообщения, которые сообщают о событиях с оборудованем.
net.* сервисы, работающие с сетевыми соединеиями и сообщения о событиях с сетью.

Запуск сервисов менеджером - для каждой шины (системной/сессионной) имеется некоторая директория, в которую помещаются скрипты, запускающие сервисы, запускаемые on-demand. Имя скрипта должно совпадать с именем, которое зарегистрирует запущенный сервис.

Процессы-гейты, обеспечивающие гейтование шины в другой транспорт (например, сообщения протокола X11) вписываются в эту систему совершенно прозрачным образом. Единственное что для каждого клиента, приконнектившегося к гейту, гейт должен вызвать
manager.Hello явным образом, чтобы получить для него uuid.

Назовем данную конструкцию мы E-Bus. Во-первых, это "неприлично" звучит, а я люблю аббревиатуры на грани фола. Во-вторых, это сокращение от easy bus, в третьих - E - следующая буква алфавита после D,

Comments

[tzirechnoy.livejournal.com]

1) Нафига uid, когда можно просто номер по порядку?
2) А чего точки, а не слэшы?
3) Добавь help aliases или help names, который бы возвращал список имён, под которым опубликован данный объект (some.server.subtree..., uuid.XXX.subtree, в таком духе).
4) Для некоторых приложэний очень жэлательно, чтобы иерархия подключений просматривалась. В смысле — кто чей родитель, кто с кем в одном дереве наследования и всё такое. По-моему, имеет смысл её сюда внедрить. Например, изменяя какое-нибудь значение в ENVIRONMENT, которое отвечает за подключение к сэссионному варианту менеджэра.
5) В связи с 4): имеет прямой смысл добавить концэпцыю параметров, указываемых при подключении. То есть что-то вроде ENV{SESS_CONNECT}="~/.ebus/sock-host COOKIE=abcdef BRANCH=uuid.123456".
Первая строка, с сокетом, эскейпиться, например, через \0xhex и \0oct для пробелов и остальных тильд. Можно, впрочем, вебовскую, как она бишь называется?
6) Большые буквы набирать муторно. То есть с этим надо что-то делать по-моему (или ignore case, или переделать имена на маленькие).
7) Предлагаю ограничить имена до us-ascii. Для передаваемых строк, которые могут буть локализованны — сделать стандартом rfc2047.
8) По-моему не нужно пользовательским приложэниям подключаться к общесистемной, если за них это можэт сделать сэссионный менеджэр. Опять жэ, толика контроля над криворукостью сисадмина появится.

[crazy-daemon.livejournal.com]

7) мне кажется лучше подойдет RFC3987

[tzirechnoy.livejournal.com]

Не, я не про имена в 2047 — это всё ересь, имена латинскими оставьте. Я про содержымое сообщений, которое будет нередко локализованным.

[crazy-daemon.livejournal.com]

А, если про содержимое -- тогда согласен.

[vitus_wagner]

Фигня какая-то? Нафига мне по 8-bit clean транспорту всякие эскейпы гонять. Есть же utf-8

[tzirechnoy.livejournal.com]

utf8 — это вымысел.

Мысль, что символы можно записать в одной таблицэ — это ересь.

[besm6.livejournal.com]

А сторонники этого подхода стройными рядами топают пользоваться D-Bus. Там их, правда, тоже обломают....

[df-org.livejournal.com]

utf-8 - тоже эскейп, только другой.

[vitus_wagner]

1) Нафига uid, когда можно просто номер по порядку?
Способ формирования uid на данный момент неспецифицирован. Может это и будет номер по порядку. 64 битный. Тогда от перезагрузки до перезагрузки точно хватит.
2) А чего точки, а не слэшы?
Почему бы и нет? Программистам на большинстве языков оно привычнее.
3) Добавь help aliases или help names, который бы возвращал список имён, под которым опубликован данный объект (some.server.subtree..., uuid.XXX.subtree, в таком духе).
Не понял. Имен у объекта может быть ровно ОДНО. Потому что объект - это поддерево в пространстве имен. Не более того. Один и тот же клиентский процесс может зарегистрировать несколько несвязанных поддеревьев. Но вообще-то это уже клиентов не касается.
4) Для некоторых приложэний очень жэлательно, чтобы иерархия подключений просматривалась. В смысле — кто чей родитель, кто с кем в одном дереве наследования и всё такое.
Какой родитель, какое наследование? Ты о чем? Единственное что из данной спецификации может представлять интерес, это какие n первых компонентов имени вызываемого метода зарегистрированы как сервис в менеджере шины, а какие m остальных - обрабатываются процессом сервиса.
5) В связи с 4): имеет прямой смысл добавить концэпцыю параметров, указываемых при подключении.
Не имеет. Преумножение сущностей.
Большые буквы набирать муторно.
Купи книжку "Соло на клавиатуре" и потренируйся. Научишься работать с клавиатурой - будет пофигу.
7) Предлагаю ограничить имена до us-ascii. Для передаваемых строк, которые могут буть локализованны — сделать стандартом rfc2047.
Ограничение имен us-ascii - это стоит подумать. Оно так проще будет обеспечивать международную кооперацию разработчиков. Но вот RFC2047 - никогда и ни за что. Текст сообщения должен передаваться в читаемом виде. Utf-8 и только UTF-8. Благо уже скоро люди забудут что бывают другие локали.
8) По-моему не нужно пользовательским приложэниям подключаться к общесистемной, если за них это можэт сделать сэссионный менеджэр. Опять жэ, толика контроля над криворукостью сисадмина появится.
Вообще говоря, система на которой выполняется программа, это не та система, на которой выполняется сессионный менеджер. И если у меня на экране ноутбука сидит окошко программы, выполнгяющейся на ноутбуке жены, а жена решила ноутбук в суспенд отправить, то программа должна получить сообщение о суспенде СВОЕЙ системы. А программы, выполняющиеся на моем ноутбуке локально - не должны получать сообщение о суспенде какой-то совершенно посторонней системы.

Правда, из этого следует, что основным транспортом сессионной шины должен быть X11, а не сокет, а гейт этого транспорта в сокетный должен быть встроен в эмулятор терминала.

[besm6.livejournal.com]

X11 бывает не всегда.

[vitus_wagner]

Ну вот когда его нету, тогда используется не-основной (fallback) транспорт.

[arilou]

> Благо уже скоро люди забудут что бывают другие локали.

Боюсь, нескоро, но поспособствовать этому конечно стоит. :)

[http://users.livejournal.com/_navi_/]

Неужто ты “The UTF-8 Monoculturists” (http://modeemi.fi/~tuomov/b/archives/2006/08/26/T20_16_06/) Туомо Вальконена не читал? Не то чтобы я апологет подхода “каждой последовательности байт содержащей строковые данные — по указанию encoding'а”, но какой-то смысл в его словах есть (я ещё не определился со своим мнением, как правильно).

[vitus_wagner]

Ну, если твой родной язык использует латиницу, можно бухтеть по поводу юникода. Но когда у меня в активном использовании ЧЕТЫРЕ кириллических локали, понимаешь, что это немножко чересчур.
Вообще, использование UTF-8 это почти что единственный работающий метод в OpenSource для того, чтобы обеспечить, чтобы англоязычные и германоязычные разработчики не сломали работу с более другими языками.

Опять же, если мы вводим НОВЫЙ стандарт, нам не нужна совместимость с legacy code. Соответственно, возни с кодировками можно и нужно избегать.

Опять же - как без utf-8 можно совместить в одной строке немецкое и русское слова?

[http://users.livejournal.com/_navi_/]

Речь не о том, что UTF-8 — это плохо. UTF-8 — это замечательно, как раз по вышеперечисленным причинам. Плохо исходить из того, что на смену ему не прийдёт какой-нибудь UTF+8 и не понадобится использовать те же протоколы с использованием его для представления строк. Соответственно, не плохо бы явно указывать кодировку (UTF-8) при сообщении. Можно даже сделать так: сказать, что сейчас единственная поддерживаемая кодировка — это UTF-8. Это конечно не значит, что при смене не будет проблем, просто их будет чуть меньше. (Ещё можно договориться, что Manager будет автоматически перекодировать сообщения в любимую приложением кодировку по его запросу — на случай, когда возня с кодировками действительно не оправдывается).

Я не совсем понял, почему „не нужна совместимость с legacy code”. К сожалению все программы в одну ночь с одного стандарта на другой не перейдут — переходить будут месяцами и годами, а взаимодействие между программами будет поломано из-за разных предположении и невозможности арбитража со стороны Manager'а из-за того, что в протоколе просто негде сказать, какая кодировка используется.

Я не уверен абсолютно во всём вышесказанном, это для меня скорее попытка прояснить все за и против.

[vitus_wagner]

UTF-8 позволяет представить коды до 42-битов. Этого хватит на все алфавиты мира, живые и мертвые, включая тенгвар и клингон, да еще и для настоящих инопланетян останется. Четыре ТРИЛЛИОНА символов.

[http://users.livejournal.com/_navi_/]

ну выделяют-то там целые блоки символов, остаётся много неиспользованного места :-)
Хотя согласен, что 42 бита — это очень много.

[vitus_wagner]

В IPv4 где когда-то выделялись блоки по 16 миллионов адресов (сети класса A) очень быстро одумались. Сначала придумали classless адресацию, а потом и большую часть блоков класса A отобрали у тех, кому они были в 80-е годы выделены, и поделили между провайдерами. Если найти где-нибудь список тех, кому были выделены сети класса A, то выяснится, что мой IP-адрес, начинающийся с 83, должен бы принадлежать какому-нибудь NASA или General Motors.

Так что выделение блоков при необходимости переигрывается.

[tzirechnoy.livejournal.com]

640K enough for everyone?

Кстати, сколько там ужэ ревизий unicode? 4? А клингона по-моему до сих пор нет. И Unihan не разделён.
По сути, klingon ужэ начал победный процэсс создания различных кодировок в рамках unicode.

Вопрос не в количестве потэнцыальных символов. Его можно легко сделать бесконечным, не в этом суть. Вопрос в том, что unicode пытается свести все человеческие символы в одну таблицу при помощи коллективного маразума. Это принцыпиально невозможно.

Более того, ужэ сейчас грепать по юникоду практически невозможно. Ясно, что для нормального поиска нужны какие-то преобразования. Это просто ещё как пример, что one size fits all не проходит.

[vitus_wagner]

Я не совсем понял, почему „не нужна совместимость с legacy code”.
Потому что этого кода ПРОСТО НЕТ. Никто не писал код работы с E-Bus, использующий 8-битные кодировки. По той простой причине что код работы с E-Bus вообще еще никто не писал.\\\

Вопрос встраивания E-Bus в существующую программу, умеющую работать в неюникодной локали - это совсем другой вопрос. Кстати, в большинстве языков программирования он УЖЕ решен на уровне языка - внутреннее представление строк что в Java, что в Tcl, что в Perl - Unicode.

Остаются только программы, написанные на портабельном ассемблере и его объектно-ориентированном расширении. Там это придется решать на уровне библиотеки. В смысле, написать libebus для этих языков так, чтобы она сразу конвертировала из текущей локали процесса в utf-8 при отправке, и обратно - при приеме.