[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

[Nikhil Marathe]

On Fri, Mar 26, 2010 at 6:56 PM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>> As for the UPnP spec, I think that Solid should export a generic UPnP
>> device system,
>
> What do you mean by this? Solid objects which implement a special
> UPnPInterface interface?
>  Wouldn't it be better if we could hide implementation details as much as
> possible? Like one does not scare if it is a IDE or SATA hard disk, they are
> all wrapped behind a neutral interface at the next level.

Well I'm not sure if the exact situation applies. IDE and SATA might
have different capabilities, but they aren't user/application level
capabilities. UPnP on the other hand is quite different from other
protocols, and in this case applications are interested in the unique
features of a UPnP device, so I think it should be offered by Solid.
That way Solid could directly give an app the exact UDN of a device
based on "Does a device support media server 3 capabilities" or
something.

>
>> For the protocol prefix, well I think upnp:/ makes more sense because
>> we are 'browsing UPnP devices'. Then for certain device types, we can
>> have upnp-<type> slaves.
>
> Why would you want to do a kio-slave to browse just UPnP devices (on the
> discovery level)? The network:/ kio-slave does that already. Where would you
> need that?
> Do you think the user cares for this implementation/technique detail and says,
> hey, let's browse just my UPnP devices? ;)

Well we let the network:/ slave handle discovery, but when a user
selects a device, we invoke the upnp:/ Actually is it possible to
spawn a slave from another slave? that would simplify stuff a lot. The
user would keep seeing network:/ but apps could use the exact slave
they require.

>> @Bart and Friedrich
>>
>> That is a good point about different kinds of files available. Perhaps
>> it could be done that Solid allows querying the device about the
>> various file types available for a given resource, and the kio-slave
>> sticks to the default. That way advanced apps can always use Solid.
>
> As much as I understood Kevin's vision with Solid the actual interaction with
> the device/service is out of scope for Solid and should be done by another
> entity, here your upnp(-ms):/ kio-slave which talks directly to the UPnP
> stuff.

Yes, after investigating Solid a bit more I think it should stick to
the discovery part, as I said above and not go to deep into querying
more than what is available on the common UPnP discovery protocol.

Regards,
Nikhil