Earlier this year I wrote a number of posts about monitoring and interacting with D-Bus using shell scripts. In this post I look at using Ruby to monitor and interact with D-Bus enabled applications.
|
|
||
|
Earlier this year I wrote a number of posts about monitoring and interacting with D-Bus using shell scripts. In this post I look at using Ruby to monitor and interact with D-Bus enabled applications. D-Bus (Desktop Bus) is a low-latency, low-overhead, easy-to-use message bus technology which supports application launch and linking. It is primarly used on GNU/Linux desktops but has been ported to other platforms including Microsoft Windows and Apple Mac OS X.  This post provides a quick overview of D-Bus concepts, some history, and some examples of how to use D-Bus in your shell scripts. Originally both the KDE and GNOME desktop projects used CORBA for inter-application communication. Over time however, for various reasons, KDE migrated from CORBA to Desktop Comunications Protocol (DCOP) and GNOME migrated to Bonono. This lead to the situation where GNU/Linux desktop distributions had to support two different inter-application lauch and linking models and many standard desktop applications could not communicate seamlessly with each other. To ameliorate this unsatisfactory situation, D-Bus (the name was suggested by Harri Porten) was conceived and developed by Red Hat as part of the freedesktop.org project. The design of D-Bus was heavily influenced by DCOP. From the start, it was designed to be a replacement for the two competing technologies. The initial source code module was created by Havoc Pennington in late 2002. Development was quite slow with many changes to the wire protocol. However by 2006 the specification was relatively stable. First GNOME and then KDE made the decision to transition to D-Bus in order to support a single unified applcation linking and lauching technology on GNU/linux desktops. In many ways D-Bus is similar to Sun Microsystems ToolTalk which is the undelying technology in Common Desktop Environment, and Microsoft’s Object Linking and Embedding (OLE) technology. The basic D-Bus protocol is a low latancy peer-to-peer or client-server binary protocol. It is not intended for inter-machine use but rather for intra-machine use. It works in terms of messages rather than byte streams. A message bus is used when many-to-many communication is desired. Normally applications communicate via such a message bus but direct application-to-application communication is also possible. When communicating on a message bus, applications can query which other applications and services are available, as well as activate one on demand. A daemon, or service, must be launched before any applications can connect to a message bus. This daemon is responsible for keeping track of the applications that are connected and for properly routing messages from source to destination. The D-Bus specification defines two well-known buses called the system bus and the session bus. Recent releases of Fedora and other GNU/Linux distributions include a Hardware Abstraction Layer (HAL) which is used to support device plug-and-play capabilities. In this post I will show you how your shell scripts can use HAL to retrieve device and system information. The term HAL is overloaded as it used to refer both to a specification and the actual software which implements the specification. From an application developers viewpoint, HAL is way to enumerate the capabilities and features of hardware attached to a system and receive notification when something about the hardware changes. First, a very quick overview of HAL. Each item of physical hardware in a computer is regarded as being an device object which identified by a Unique Device Identifier (UDI). Associated with each device object is a variable set of well-defined typed key-value pairs (or metadata) called device properties which describe what each device object represents together with its properties. Some device properties are derived from the actual physical hardware, some are merged from XML-formatted files, known as Device Information Files, and some are derived from the actual device configuration. Mandatory device properties are defined in the HAL specification. A HAL |
||
|
Copyright © 2005-2012 Finnbarr P. Murphy. All Rights Reserved. |
||