The udbus package

[Tags: bsd3, library]

Small and flexible implementation of the dbus protocol.

[Skip to ReadMe]


Versions0.1, 0.1.1, 0.2.0, 0.2.1
Change logNone available
Dependenciesbase (>=3 && <5), binary, bytestring, cereal, containers, ghc-prim, mtl, network, QuickCheck (>=2), test-framework, test-framework-quickcheck2, unix, utf8-string [details]
CopyrightVincent Hanquez <>
AuthorVincent Hanquez <>
MaintainerVincent Hanquez <>
Home page
Source repositoryhead: git clone git://
ExecutablesTests, dbus
UploadedWed Jul 23 14:51:34 UTC 2014 by VincentHanquez
Downloads1002 total (40 in last 30 days)
0 []
StatusDocs available [build log]
Successful builds reported [all 1 reports]




testBuild unit testDisabledAutomatic
executableBuild the executableDisabledAutomatic

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


Maintainers' corner

For package maintainers and hackage trustees

Readme for udbus-0.2.1


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