LXF99:D-Bus - История изменений

StavNight0ver: /* Подключайтесь! */

2009-10-11T11:41:28Z

‎Подключайтесь!

Crazy Rebel: /* D-Bus: шины для вашего Linux */

2008-11-27T07:11:36Z

‎D-Bus: шины для вашего Linux

Crazy Rebel: /* Подключайтесь! */

2008-11-27T07:10:39Z

‎Подключайтесь!

Crazy Rebel в 07:30, 17 ноября 2008

2008-11-17T07:30:38Z

Lockal: восстановление кавычек в коде AWB

2008-04-27T14:55:22Z

восстановление кавычек в коде AWB

Crazy Rebel: /* Немного об архитектуре */

2008-03-17T09:27:37Z

‎Немного об архитектуре

Crazy Rebel: Новая: ===D-Bus: шины для вашего Linux=== Уже успели подумать о зимней резине или переломах и вывихах? Возвращайтесь...

2008-03-14T06:44:55Z

Новая: ===D-Bus: шины для вашего Linux=== Уже успели подумать о зимней резине или переломах и вывихах? Возвращайтесь...

Внесённые изменения

@@ Строка 52: / Строка 52: @@
     DBusMessage *call;
     DBusMessage *reply;
-    const char * arg = "PROTOCOL 6\n"
+    const char * arg = "PROTOCOL 6\n";
     char * response = NULL;
     dbus_error_init(&error);

@@ Строка 2: / Строка 2: @@
 ===D-Bus: шины для вашего Linux===
-Уже успели подумать о зимней резине или переломах и вывихах? Возвращайтесь обратно в виртуальный мир – '''Андрей Боровский''' имеет в виду шину для обмена данными между настольными приложениями!
+: Уже успели подумать о зимней резине или переломах и вывихах? Возвращайтесь обратно в виртуальный мир – '''Андрей Боровский''' имеет в виду шину для обмена данными между настольными приложениями!
-Что такое D-Bus? Самый простой ответ – еще одна система межпроцессного взаимодействия (Interprocess Communication или IPC). Ключевые слова здесь «еще одна». Высокоуровневых систем IPC для Unix/Linux существует много. Помимо систем высокого уровня Unix обладает развитыми средствами IPC низкого уровня (сокеты, каналы), каковые успешно используются многими приложениями напрямую. Зачем тогда нам может понадобиться D-Bus? Эта система замышлялась группой ''FreeDesktop.org'' как средство IPC, не зависящее от типа рабочего стола, призванное заменить как DCOP в KDE, так и CORBA/Bonobo в GNOME. Вытеснить родные средства IPC KDE и GNOME новой системе пока не удалось [правда, в KDE 4 D-Bus все-таки будет использоваться вместо DCOP, ''– прим. ред.''], но в процессе разработки D-Bus обрела несколько уникальных и полезных особенностей. Важными отличительными чертами D-Bus являются система сигналов и асинхронных вызовов методов, а также система управления выполнением приложений. Таким образом, ответ на вопрос, зачем вам может понадобиться программирование D-Bus, состоит из двух частей. Во-первых, многие важные приложения и системные компоненты (например, Linux HAL и NetworkManager) используют D-Bus как средство общения с внешним миром. Во вторых, D-Bus – это платформенно-независимая система IPC, которая присутствует практически в каждом дистрибутиве Linux и устанавливается по умолчанию во многих из них. Поэтому, если вы пишете приложение, которое должно предоставлять сервисы IPC, не являясь частью какого-либо рабочего стола, вам, безусловно, имеет смысл обратить внимание на D-Bus. При этом следует учитывать и минусы D-Bus. В системе все еще не реализована связь между разными машинами, хотя работа в этом направлении ведется. D-Bus легко может быть перенесена на другие Unix-платформы, но ее версия для Windows по-прежнему далека от завершения.
+Что такое D-Bus? Самый простой ответ – еще одна система межпроцессного взаимодействия (Interprocess Communication или IPC). Ключевые слова здесь «еще одна». Высокоуровневых систем IPC для Unix/Linux существует много. Помимо систем высокого уровня Unix обладает развитыми средствами IPC низкого уровня (сокеты, каналы), каковые успешно используются многими приложениями напрямую. Зачем тогда нам может понадобиться D-Bus? Эта система замышлялась группой ''FreeDesktop.org'' как средство IPC, не зависящее от типа рабочего стола, призванное заменить как DCOP в KDE, так и CORBA/Bonobo в GNOME. Вытеснить родные средства IPC KDE и GNOME новой системе пока не удалось ['''правда, в KDE 4 D-Bus все-таки будет использоваться вместо DCOP, – прим. ред.'''], но в процессе разработки D-Bus обрела несколько уникальных и полезных особенностей. Важными отличительными чертами D-Bus являются система сигналов и асинхронных вызовов методов, а также система управления выполнением приложений. Таким образом, ответ на вопрос, зачем вам может понадобиться программирование D-Bus, состоит из двух частей. Во-первых, многие важные приложения и системные компоненты (например, Linux HAL и NetworkManager) используют D-Bus как средство общения с внешним миром. Во вторых, D-Bus – это платформенно-независимая система IPC, которая присутствует практически в каждом дистрибутиве Linux и устанавливается по умолчанию во многих из них. Поэтому, если вы пишете приложение, которое должно предоставлять сервисы IPC, не являясь частью какого-либо рабочего стола, вам, безусловно, имеет смысл обратить внимание на D-Bus. При этом следует учитывать и минусы D-Bus. В системе все еще не реализована связь между разными машинами, хотя работа в этом направлении ведется. D-Bus легко может быть перенесена на другие Unix-платформы, но ее версия для Windows по-прежнему далека от завершения.
 Среди конкурирующих технологий (в том смысле, что их зачастую можно использовать вместо D-Bus), следует отметить CORBA, SOAP, XML-RPC, DCOM, DCOP, Bonobo. Чем D-Bus отличается от них? CORBA, как и D-Bus, использует быстрый бинарный протокол. В отличие от D-Bus, CORBA предназначается для решения чрезвычайно широкого круга задач и может использоваться как в локальной, так и в распределенной системе. В CORBA отсутствуют такие элементы D-Bus, как система управления выполнением приложений и система сигналов. SOAP и XML-RPC представляют собой протоколы, в которых на низком уровне активно используется XML. Эти технологии межпроцессного взаимодействия хорошо подходят для Интернета, однако при обмене данными между приложениями, работающими на одной машине, использование механизмов XML приводит к пустой трате ресурсов (при этом надо отметить, конечно, что приложения, использующие эти протоколы, чрезвычайно легко масштабируются). Технологии DCOM, DCOP и Bonobo имеют один сходный недостаток – каждая из них предназначена для конкретной платформы (Windows, KDE и GNOME соответственно), и организовать взаимодействие между приложениями разных платформ с их помощью будет весьма непросто.

@@ Строка 43: / Строка 43: @@
 Следующий код представляет собой минимальную программу, использующую возможности D-BUS.
-<code>
+<source lang=c>
   #include <stdio.h>
   #include <dbus/dbus.h>
@@ Строка 77: / Строка 77: @@
    return 0;
+  }
-</code>
+</source>
 Объявления типов и функций, связанные с D-Bus API, становятся доступны программе при включении в ее текст заголовочного файла '''dbus/dbus.h''' (где найти этот файл, знает команда ''pkg-config  --cflags dbus-1''). Соединение с сервером D-Bus устанавливается с помощью функции '''dbus_bus_get()'''. Ее первый параметр указывает, к какой шине, системной или пользовательской, мы хотим подключиться (в данном случае выбирается пользовательская шина – '''DBUS_BUS_SESSION'''). Вторым параметром должен быть указатель на переменную типа '''DBusError'''. Если в процессе подключения к шине произойдет сбой, функция '''dbus_bus_get()''' вернет значение '''NULL''', а в переменной ''error'' будет записана информация об ошибке.
@@ Строка 90: / Строка 90: @@
 На этом работа нашей программы окончена. С помощью функций '''dbus_message_unref()''' и '''dbus_connection_unref()''' мы сообщаем системе, что созданные нами объекты интерфейса D-Bus нам больше не нужны, и выделенную под них память можно освободить.
 ====А дальше?====

← Предыдущая		Версия 07:30, 17 ноября 2008
Строка 1:		Строка 1:
		+	[[Категория:Учебники]]
	===D-Bus: шины для вашего Linux===		===D-Bus: шины для вашего Linux===

@@ Строка 30: / Строка 30: @@
 Совокупность методов и сигналов, предоставляемых объектом D-Bus, называется интерфейсом объекта D-Bus. Декларируя поддержку определенного интерфейса, объект гарантирует определенную реакцию на сообщения, поступающие извне. Каждый объект может поддерживать несколько интерфейсов, которые, естественно, различаются по именам. Некоторую путаницу создает тот факт, что имена интерфейсов имеют ту же структуру, что и имена соединений (и часто совпадают с ними). Например, объект '''/com/Skype''' экспортирует интерфейс '''com.Skype.API''' (такое же имя имеет соединение, которое создает клиент ''Skype''). Итак, для передачи сообщения другой программе с помощью D-Bus, необходимо знать имя соединения этой программы с демоном D-Bus, имя объекта и имя интерфейса. Для вызова метода, декларируемого интерфейсом, нужно, конечно, знать еще и имя метода. Вы можете придти к выводу, что для того, чтобы обмениваться сообщениями D-Bus с другой программой, вам всегда необходимо создавать объект D-Bus и декларировать поддержку некоторого интерфейса. На самом деле, это не обязательно. Если ваша программа использует D-Bus только для вызова методов объектов других приложений, никаких специальных действий по регистрации объектов выполнять не требуется. Более того, вам не придется придумывать для вашей программы и имя соединения – в процессе подключения к шине демон D-Bus создаст его автоматически. Сгенерированное имя будет иметь вид ''':x.y''', где '''x''' и '''y''' – некоторые числа. На самом деле, подобное имя создается для каждого соединения D-Bus в рамках данной сессии, и именно оно используется демоном для передачи сообщений. В случае с программами, зарегистрировавшими сервисы D-Bus, имя, начинающееся с двоеточия, является синонимом постоянного имени (такого как '''com.Skype.API''') в рамках текущей сессии. Если рассматривать программу, предоставляющую сервис D-Bus, как аналог web-сервера, то имя соединения, начинающееся с двоеточия, можно сравнить с IP-адресом сервера, а постоянное имя – с доменным именем. Иерархия различных элементов D-BUS представлена на Рис. 1.
-[[Изображение:LXF99_DBUS1.jpg|Рис. 1. Схема взаимодействия двух приложений с помощью D-Bus.]]
+[[Изображение:LXF99 DBUS1.jpg|Рис. 1. Схема взаимодействия двух приложений с помощью D-Bus.]]
 Хотя вы и не можете работать с объектами D-Bus напрямую, система предоставляет программистам объектоподобный интерфейс, который реализуется с помощью так называемых прокси-объектов ('''proxy objects'''). Прокси можно считать представителем объекта D-Bus в вашей программе. Насколько прокси-объект похож на «настоящий» – зависит от реализации. В языках Java и Python работа с прокси осуществляется практически так же, как с «настоящими» объектами языка. При использовании интерфейсов библиотеки ''GLib'' для работы с прокси применяется специальный набор функций.
@@ Строка 51: / Строка 51: @@
     DBusMessage *call;
     DBusMessage *reply;
-    const char * arg = “PROTOCOL 6\n”
+    const char * arg = "PROTOCOL 6\n"
     char * response = NULL;
     dbus_error_init(&error);
     connection = dbus_bus_get(DBUS_BUS_SESSION, &error);
     if (!connection) {
-      printf(“Ошибка соединения с D-BUS: %s\n”, error.message);
+      printf("Ошибка соединения с D-BUS: %s\n", error.message);
      dbus_error_free(&error);
      return 1;
+   }
-   call = dbus_message_new_method_call(“com.Skype.API”, “/com/Skype”, “com.Skype.API”, “Invoke”);
+   call = dbus_message_new_method_call("com.Skype.API", "/com/Skype", "com.Skype.API", "Invoke");
    dbus_message_append_args (call, DBUS_TYPE_STRING, &arg, DBUS_TYPE_INVALID);
    reply = dbus_connection_send_with_reply_and_block (connection, call, 100000, &error);
    if (!reply) {
-     printf(“Ошибка вызова метода: %s\n”, error.message);
+     printf("Ошибка вызова метода: %s\n", error.message);
      dbus_error_free(&error);
      return 1;
@@ Строка 70: / Строка 70: @@
    dbus_message_get_args (reply, &error, DBUS_TYPE_STRING, &response, DBUS_TYPE_INVALID);
    if (response != NULL)
-     printf(“Ответ: %s\n”, response);
+     printf("Ответ: %s\n", response);
    dbus_message_unref(call);
    dbus_message_unref(reply);

← Предыдущая		Версия 09:27, 17 марта 2008
Строка 29:		Строка 29:

	Совокупность методов и сигналов, предоставляемых объектом D-Bus, называется интерфейсом объекта D-Bus. Декларируя поддержку определенного интерфейса, объект гарантирует определенную реакцию на сообщения, поступающие извне. Каждый объект может поддерживать несколько интерфейсов, которые, естественно, различаются по именам. Некоторую путаницу создает тот факт, что имена интерфейсов имеют ту же структуру, что и имена соединений (и часто совпадают с ними). Например, объект '''/com/Skype''' экспортирует интерфейс '''com.Skype.API''' (такое же имя имеет соединение, которое создает клиент ''Skype''). Итак, для передачи сообщения другой программе с помощью D-Bus, необходимо знать имя соединения этой программы с демоном D-Bus, имя объекта и имя интерфейса. Для вызова метода, декларируемого интерфейсом, нужно, конечно, знать еще и имя метода. Вы можете придти к выводу, что для того, чтобы обмениваться сообщениями D-Bus с другой программой, вам всегда необходимо создавать объект D-Bus и декларировать поддержку некоторого интерфейса. На самом деле, это не обязательно. Если ваша программа использует D-Bus только для вызова методов объектов других приложений, никаких специальных действий по регистрации объектов выполнять не требуется. Более того, вам не придется придумывать для вашей программы и имя соединения – в процессе подключения к шине демон D-Bus создаст его автоматически. Сгенерированное имя будет иметь вид ''':x.y''', где '''x''' и '''y''' – некоторые числа. На самом деле, подобное имя создается для каждого соединения D-Bus в рамках данной сессии, и именно оно используется демоном для передачи сообщений. В случае с программами, зарегистрировавшими сервисы D-Bus, имя, начинающееся с двоеточия, является синонимом постоянного имени (такого как '''com.Skype.API''') в рамках текущей сессии. Если рассматривать программу, предоставляющую сервис D-Bus, как аналог web-сервера, то имя соединения, начинающееся с двоеточия, можно сравнить с IP-адресом сервера, а постоянное имя – с доменным именем. Иерархия различных элементов D-BUS представлена на Рис. 1.		Совокупность методов и сигналов, предоставляемых объектом D-Bus, называется интерфейсом объекта D-Bus. Декларируя поддержку определенного интерфейса, объект гарантирует определенную реакцию на сообщения, поступающие извне. Каждый объект может поддерживать несколько интерфейсов, которые, естественно, различаются по именам. Некоторую путаницу создает тот факт, что имена интерфейсов имеют ту же структуру, что и имена соединений (и часто совпадают с ними). Например, объект '''/com/Skype''' экспортирует интерфейс '''com.Skype.API''' (такое же имя имеет соединение, которое создает клиент ''Skype''). Итак, для передачи сообщения другой программе с помощью D-Bus, необходимо знать имя соединения этой программы с демоном D-Bus, имя объекта и имя интерфейса. Для вызова метода, декларируемого интерфейсом, нужно, конечно, знать еще и имя метода. Вы можете придти к выводу, что для того, чтобы обмениваться сообщениями D-Bus с другой программой, вам всегда необходимо создавать объект D-Bus и декларировать поддержку некоторого интерфейса. На самом деле, это не обязательно. Если ваша программа использует D-Bus только для вызова методов объектов других приложений, никаких специальных действий по регистрации объектов выполнять не требуется. Более того, вам не придется придумывать для вашей программы и имя соединения – в процессе подключения к шине демон D-Bus создаст его автоматически. Сгенерированное имя будет иметь вид ''':x.y''', где '''x''' и '''y''' – некоторые числа. На самом деле, подобное имя создается для каждого соединения D-Bus в рамках данной сессии, и именно оно используется демоном для передачи сообщений. В случае с программами, зарегистрировавшими сервисы D-Bus, имя, начинающееся с двоеточия, является синонимом постоянного имени (такого как '''com.Skype.API''') в рамках текущей сессии. Если рассматривать программу, предоставляющую сервис D-Bus, как аналог web-сервера, то имя соединения, начинающееся с двоеточия, можно сравнить с IP-адресом сервера, а постоянное имя – с доменным именем. Иерархия различных элементов D-BUS представлена на Рис. 1.
		+
		+	[[Изображение:LXF99_DBUS1.jpg\|Рис. 1. Схема взаимодействия двух приложений с помощью D-Bus.]]

	Хотя вы и не можете работать с объектами D-Bus напрямую, система предоставляет программистам объектоподобный интерфейс, который реализуется с помощью так называемых прокси-объектов ('''proxy objects'''). Прокси можно считать представителем объекта D-Bus в вашей программе. Насколько прокси-объект похож на «настоящий» – зависит от реализации. В языках Java и Python работа с прокси осуществляется практически так же, как с «настоящими» объектами языка. При использовании интерфейсов библиотеки ''GLib'' для работы с прокси применяется специальный набор функций.		Хотя вы и не можете работать с объектами D-Bus напрямую, система предоставляет программистам объектоподобный интерфейс, который реализуется с помощью так называемых прокси-объектов ('''proxy objects'''). Прокси можно считать представителем объекта D-Bus в вашей программе. Насколько прокси-объект похож на «настоящий» – зависит от реализации. В языках Java и Python работа с прокси осуществляется практически так же, как с «настоящими» объектами языка. При использовании интерфейсов библиотеки ''GLib'' для работы с прокси применяется специальный набор функций.