The udbus package

[Tags:bsd3, library]

Small and flexible implementation of the dbus protocol.

[Skip to Readme]


Versions 0.1, 0.1.1, 0.2.0, 0.2.1
Dependencies base (>=3 && <5), binary, bytestring, cereal, containers, ghc-prim, mtl, network, QuickCheck (>=2), test-framework, test-framework-quickcheck2, unix, utf8-string [details]
License BSD3
Copyright Vincent Hanquez <>
Author Vincent Hanquez <>
Maintainer Vincent Hanquez <>
Category Network
Home page
Source repository head: git clone git://
Uploaded Wed Feb 27 14:24:50 UTC 2013 by VincentHanquez
Distributions NixOS:0.2.1
Downloads 1311 total (14 in the last 30 days)
0 []
Status Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI





Build unit test


Build the executable


Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info


Maintainer's Corner

For package maintainers and hackage trustees

Readme for udbus

Readme for udbus-0.2.0


The udbus haskell package provides a BSD implementation of the DBus protocol in pure Haskell, giving access to a simple lowlevel (Network.DBus.Actions) interface and a simple high level interface with a simple mainloop dispatcher (Network.DBus)

The interfaces are coherent and basic, sacrificing some ease of use (in using more appropriate haskell types for dbus array for example) in favor of being able to write generated code easily.

The code doesn't check if the object values (objectpath, interface, etc) are appropriates on sending, nor on receiving. The dbus daemon should have prevented invalid values to be received, and for sending, the user need to take extra care of the values sent.

TODO & Caveats

User should always select little endian regardless of the actual machine architecture when creating message. However, receiving message in both endianness is supported.

Double are expected to be handled as IEEE754 by the compiler. Serialization of double is handled in a GHC specific way (making the package GHC specific), expecting that any architecture represent double the IEEE754 way. So far, this seems to be true for every architecture supported by GHC.


While the low level interfaces should remains the same, it's not unexpected that some high level interface would be grafted on top of the actual interfaces.


A simple example on how to use the interfaces is available at the root of the package as DBus.hs