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

[Friedrich W. H. Kossebau]

Jeudi, le 25 mars 2010, à 10:33, Nikhil Marathe a écrit:
> Thanks for the feedback everybody!
> 
> @Friedrich
> 
> I will be investigating the existing infrastructure this Weekend,
> though I've already had a glance at it.
> 
> 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.

> and perhaps we can have special handlers for some
> common types like Lighting control. I have the spec downloaded, and it
> just requires reading :D That apart, for the moment I think only the
> MediaServer part makes sense, since that is pretty widespread and
> something relevant to everybody. It is also the only type for which a
> kio-slave and Amarok integration makes sense, so I will concentrate on
> that.

Yes, concentrating on the MediaServer{1,2,3} would be helpful to get things 
done, should fill the summer already :)

> 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? ;)

> I have thought of sticking to the HTTP url for items whenever
> possible, as we already have a very good slave for it. Again, on the
> weekend I'll figure out other supported protocols**.
> 
> @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.

Good luck with your exams :)

Cheers
Friedrich
-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta