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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
