[Kde-hardware-devel] Solid UPnP GSoC idea

[Bart Cerneels]

2010/4/7 Kevin Ottens <ervin at kde.org>:
> On Tuesday 6 April 2010 13:46:02 Bart Cerneels wrote:
>> The recent discussion here and on melange have shown that UPnP is a
>> very interesting, but also a very large topic for a single GSoC
>> student.
>> Since GSoC is intended for learning and contributor integration rather
>> then burning people out, I decided to make a new GSoC proposal.
>>
>> http://community.kde.org/GSoC/2010/Ideas#Project:_Network_Device_Detection_
>> .26_Desktop_Integration_for_UPnP
>
> I've been thinking about that as well, I didn't go for it though as I
> seriously doubt it'd keep someone busy for three months. Hence why I proposed
> a couple more small and simple targets for Nikhil proposal (which I wouldn't
> have done if it had a risk of having him burning out).
>
>> This proposal focuses on the Solid detection side
>
> Which is already half there thanks to Friedrich work (if we stick to
> Coherence). It would need to be redone for a HUPnP based one though.

We should make HUPnP part of the proposal then. But with some
abstraction to allow different backends. Some platforms have native
backends that can not be bypassed because of resource and security
restrictions.

>
>> and also various
>> smaller integrations into KDE SC. Examples I can think of:
>> - Plasma device notifier extended to list UPnP mediaserver shares.
>
> Trivial to do really, it's about tweaking a desktop file and at worst
> modifying a couple of lines of code.
>
>> With extra info like IP address, netbios- or hostname, etc
>> - Gateway listed in KNetworkManager tooltip, with list of forwarded
>> ports and a direct link to the management page.
>
> I don't really have an opinion about that.
>
>> - Network neighborhood plasma widget.
>
> That's probably the bit which would require the most work... and I don't see
> it being large.
>
>> The UPnP backend for Solid will test the architecture in preparation
>> for other local network protocols: DAAP, Bonjour, netbios, ...
>>
>> We have 2 candidates for UPnP, so logistically we are set. Don't let
>> that prevent interested students from applying though.
>
> Well, one of them seems to be pretty much focused on one particular UPnP stack
> only and that's the one completely unknown to me.
>
> Note that we're two days near the deadline, I somehow doubt someone will pull
> off such a proposal in a so short timeframe.
>
> Regards.

There is another task I was thinking of that would be hugely useful.
Paulo seems to be in the best position to implement it as well:

Once we ship KDE SC with UPnP integration there are going to be a lot
of bug reports by people unfamiliar with the technology and hence
unable to debug. Since a lot of problems will be caused by bad device
implementations we should get as much info about the local UPnP
environment as possible.
For this we can create a data-gathering application, probably using
python, that will help us developers hugely by reducing the required
skill level of the UPnP bug-reporters.

Clearly this needs access to some UPnP devices in a testing lab
setting as well as some experience with an established UPnP framework
different then the backend KDE is using. After all, we can't rule out
library bugs when we use the same one for gathering the debug data.
Some packaging experience will help as well, it should be an easy to
use, preferably self-contained binary or self-installable script with
a simple UI and a direct upload function to bugs.kde.org.

Bart