udbus: Small DBus implementation

[ bsd3, library, network ] [ Propose Tags ]

Small and flexible implementation of the dbus protocol.

[Skip to Readme]


Automatic Flags

Build unit test


Build the executable


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


Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS] 0.1, 0.1.1, 0.2.0, 0.2.1, 0.2.2, 0.2.3
Dependencies base (>=4.9 && <5), binary, bytestring, cereal, containers, ghc-prim, mtl, network, QuickCheck (>=2), test-framework, test-framework-quickcheck2, unix, utf8-string [details]
License BSD-3-Clause
Copyright Vincent Hanquez <vincent@snarc.org>
Author Vincent Hanquez <vincent@snarc.org>
Maintainer Vincent Hanquez <vincent@snarc.org>
Revised Revision 1 made by HerbertValerioRiedel at 2018-10-01T17:51:55Z
Category Network
Home page http://github.com/vincenthz/hs-udbus
Source repo head: git clone git://github.com/vincenthz/hs-udbus
Uploaded by VincentHanquez at 2018-03-07T13:43:01Z
Distributions NixOS:0.2.3
Reverse Dependencies 3 direct, 0 indirect [details]
Executables Tests, dbus
Downloads 4511 total (1 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2018-03-07 [all 1 reports]

Readme for udbus-0.2.3

[back to package description]


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