[Kde-hardware-devel] Of UPnP and GSoC and integration

[Kevin Ottens]

On Tuesday 30 March 2010 10:55:06 Bart Cerneels wrote:
> Having only that info would make it useless for our purpose. The UPnP
> slave needs to know
> 1) it's a UPnP media server (version is irrelevant since it's
> backwards compatible)
> 2) the Unique Device Number (a uuid) or IP address, preferably that is
> native to device model and IP version independent.
> 
> And if you want to launch a browser from, lets say a hypothetical
> plasma "Network Device Notifier" you need to know it's UPnP to launch
> kfm upnp://<uuid>

Well, actually StorageAccess is providing a (badly named) filePath() method 
for which we return the "mountpoint" of the storage device.

The way I see it, we'd forge the right upnp:// URL which would encode all the 
information needed for the ioslave itself. Actually the nice side effect is 
that you wouldn't need to do any discoverability (ok, I'm kind of ignoring the 
uuid to IP/port mapping here) at all in the ioslave as that would be covered 
by libsolid.

> StorageAccess is on a different abstraction level: based on this it's
> listed in NDM.

NDM?

Note that obviously that doesn't prevent having a more specialized MediaServer 
(for instance) interface *as* *well* if needed. But there's really a huge win 
in supporting StorageAccess on those devices, namely that we won't need to 
modify our existing applications to suddenly see your media server as an extra 
disk (think Dolphin, KFileDialog, the Plasma device notifier).

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100330/dc8e209b/attachment.sig