[Kde-hardware-devel] UPnP integration in the network:// kio-slave

Friedrich W. H. Kossebau kossebau at kde.org
Thu Sep 24 23:43:44 CEST 2009


Hi,

Jeudi, le 24 septembre 2009, à 22:50, Bart Cerneels a écrit:
> Hi all,
>
> Friedrich asked for this in a private mail. Let me dump my understanding of
> the
>
> For a technical point of view I think the only thing that is needed to
> integrate UPnP in network:// is an implementation of Mollet::Network
> and Service. Because we use Coherence's DBus interface, at least at
> first, this would come down to a simple mapping from the DBus signals
> to Qt devicesAdded, devicesRemoved, servicesAdded and servicesRemoved
> and the methods.

No, not an implementation of Mollet::Network, but an implementation of 
Mollet::AbstractNetworkBuilder. The idea of the network classes in 
kdebase/runtime/kioslave/network/network is that the devices and services 
found by the different discovery frameworks are merged into a single neutral 
view of the network. At least I found this a good idea, as I do not care how 
a service/device is found, just that it is :)

See
http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/network/network/README?view=markup
for some more explanation.

The merging is a little challenge as I have found while working on a LISa 
backend. But should be solvable somehow.

> The DBus interface for device discovery I've been playing around with
> for an Amarok Collection. As far as I can tell the Coherence side of
> this is complete. At the first UPnP sprint in May we were working on
> access to the content of a mediaserver. This is out of scope of the
> network slave though.

Sure.

Then it might perhaps be nice if the network layer can create service proxy 
objects, as provided by plugins, loaded on demand. Just like one loads a 
KPart as a handler for a filetype. So the developer simply has to develop 
against some abstract interface for a resource, as provided by the plugin, 
and does not need to know which the protocol to the remote resource is 
actually. KServiceTypeTrader might have some mork work coming to it... ;)

> The services i don't have an answer for yet. But i'm sure we can
> address this at the next sprint little over a week from now.

I see if I will make it there. Just missed you, Bart, in #coherence, will try 
again tomorrow morning.

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta


More information about the Kde-hardware-devel mailing list