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

Bart Cerneels bart.cerneels at kde.org
Tue Mar 30 10:55:06 CEST 2010


On Fri, Mar 26, 2010 at 14:11, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Mercredi, le 24 mars 2010, à 12:39, Bart Cerneels a écrit:
>> On Fri, Mar 19, 2010 at 18:39, Nikhil Marathe <nsm.nikhil at gmail.com> wrote:
>> > Hi,
>> >
>> > I'm Nikhil Marathe. I am applying for the Amarok/KDE UPnP integration.
>> > I have already been in talks with
>> > Bart Cerneels about some things but I had a question about the exact
>> > scope of Solid with respect to UPnP.
>> >
>> > It seems to me that Solid will simply run the daemon which will watch
>> > for appearing and disappearing UPnP
>> > devices. It will be the KIO slave which will actually handle the
>> > details such as querying the device about
>> > services it provides and so on. So Solid maintains some kind of a
>> > cache. Am I correct?
>>
>> I would like to know this as well. Will Solid list the services
>> supported by a detected network device?
>
> In UPnP terms you mean "Will Solid list the UPnP devices supported by a
> detected network rootdevice?", right?
>
> So yes, it will. But it will do by trying to hide the fact they are UPnP
> devices as much as possible, instead try to use common interfaces.
>
>> Ideally this will work:
>>
>> solid-hardware query "UPnP.DeviceType ==
>> 'urn:schemas-upnp-org:device:MediaServer:2"
>>
>> or at similar at service level.
>
> Is this ideally? Wouldn't it be more ideal if you rather query for
>
> solid-hardware query "IS StorageAccess"

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>

StorageAccess is on a different abstraction level: based on this it's
listed in NDM. The UPnP info is used to launch the correct kio-slave.
So a UPnP MediaServer will have both sets of info.

>
> (hm, no time to make something up, but think of generic stuff).
>
> But you may be right, an interface to query UPnP device specific stuff could
> be useful, as long as the client has to know about the UPnP nature of the
> object it operates on and cannot deal with them via generic interfaces.
>
> On a related note I wonder: Shouldn't a DAAP service (which I consider similar
> to a MediaServerX service) not also be rendered as a device by Solid, then?
> Where is the difference?
> What makes a system a device, what makes a system a service?

Yes it should. Though I'm not sure if the protocol supports browse,
you might need to create virtual folders that match certain searches
like Artist/Album/Track or Genre/Artist/Album/Track. Then you must
also make this configurable in system-settings.

>
> (I guess the DAAP kio-slave from Benjamin Meyer only died because of the not-
> yet re-engineered newer protocol, right?)
>

That and time, moving on to better protocols, etc. Then again, we
managed to use it in Amarok right (though that might be the
non-encrypted, FLOSS friendly old protocol).


More information about the Kde-hardware-devel mailing list