Netzflocken

...was so an- und abfällt

UPnP <-> D-Bus pontoon (*)

written by dev, on Sep 23, 2007 7:35:00 PM.

I just checked in a new version of Coherence with a provisional integration of the D-Bus message bus system.

D-Bus support within Coherence will be divided into two parts:

  1. accessing UPnP devices and services via D-Bus as a client
    • notification about the emergence of new devices and their disappearance
    • access to the API of the Coherence service clients, for instance the Browse method of the ContentDirectoryService
    • signaling of UPnP service StateVariable changes
  2. providing the backend functionality for an UPnP device
    There I'm think off two ways to achieve this:
    • a dedicated plugin for each backend that proxies the UPnP action to their respective backend method, like we do this already for instance in the Elisa backend, using Twisted Perspective Broker as RPC protocol.
    • a generic D-Bus hooking-in system, that can be used to initiate a UPnP device creation via DBus and to tell Coherence which DBus methods should be called on recieving an UPnP action request
The first part is working, lacking the signaling of the StateVariable changes though. That added it will be very,very easy to supply UPnP A/V MediaServer browsing capabilities to any D-Bus talking application. E.g. replacing the Rhythmbox Coherence UPnP plugins, which have to be in Python at the moment, with some native code.

The second one I'm still contemplating about on how to implement it in a plain and standard style, that allows an application to ask Coherence to create an UPnP device with its services - not only an A/V device, but others too, even non-standard ones - to publish so far locally restricted D-Bus services out onto the network.

* It is no full bridge yet - at least not in my opinion, at the moment it is more looking like something really simple timbered together. ;-)

Leave a Reply