[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