<div class="gmail_quote">2010/4/8 Bart Cerneels <span dir="ltr"><<a href="mailto:bart.cerneels@kde.org">bart.cerneels@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">2010/4/7 Kevin Ottens <<a href="mailto:ervin@kde.org">ervin@kde.org</a>>:<br>
> On Tuesday 6 April 2010 13:46:02 Bart Cerneels wrote:<br>
</div><div class="im">>> The recent discussion here and on melange have shown that UPnP is a<br>
>> very interesting, but also a very large topic for a single GSoC<br>
>> student.<br>
>> Since GSoC is intended for learning and contributor integration rather<br>
>> then burning people out, I decided to make a new GSoC proposal.<br>
>><br>
>> <a href="http://community.kde.org/GSoC/2010/Ideas#Project:_Network_Device_Detection_" target="_blank">http://community.kde.org/GSoC/2010/Ideas#Project:_Network_Device_Detection_</a><br>
>> .26_Desktop_Integration_for_UPnP<br>
><br>
</div>> I've been thinking about that as well, I didn't go for it though as I<br>
> seriously doubt it'd keep someone busy for three months. Hence why I proposed<br>
> a couple more small and simple targets for Nikhil proposal (which I wouldn't<br>
> have done if it had a risk of having him burning out).<br>
<div class="im">><br>
>> This proposal focuses on the Solid detection side<br>
><br>
</div><div class="im">> Which is already half there thanks to Friedrich work (if we stick to<br>
> Coherence). It would need to be redone for a HUPnP based one though.<br>
<br>
</div>We should make HUPnP part of the proposal then. But with some<br>
abstraction to allow different backends. Some platforms have native<br>
backends that can not be bypassed because of resource and security<br>
restrictions.<br>
<div class="im"><br>
><br>
>> and also various<br>
>> smaller integrations into KDE SC. Examples I can think of:<br>
>> - Plasma device notifier extended to list UPnP mediaserver shares.<br>
><br>
</div>> Trivial to do really, it's about tweaking a desktop file and at worst<br>
> modifying a couple of lines of code.<br>
<div class="im">><br>
>> With extra info like IP address, netbios- or hostname, etc<br>
>> - Gateway listed in KNetworkManager tooltip, with list of forwarded<br>
>> ports and a direct link to the management page.<br>
><br>
</div>> I don't really have an opinion about that.<br>
><br>
>> - Network neighborhood plasma widget.<br>
><br>
> That's probably the bit which would require the most work... and I don't see<br>
> it being large.<br>
<div class="im">><br>
>> The UPnP backend for Solid will test the architecture in preparation<br>
>> for other local network protocols: DAAP, Bonjour, netbios, ...<br>
>><br>
>> We have 2 candidates for UPnP, so logistically we are set. Don't let<br>
>> that prevent interested students from applying though.<br>
><br>
</div>> Well, one of them seems to be pretty much focused on one particular UPnP stack<br>
> only and that's the one completely unknown to me.<br>
><br>
> Note that we're two days near the deadline, I somehow doubt someone will pull<br>
> off such a proposal in a so short timeframe.<br>
><br>
> Regards.<br>
<br>
There is another task I was thinking of that would be hugely useful.<br>
Paulo seems to be in the best position to implement it as well:<br>
<br>
Once we ship KDE SC with UPnP integration there are going to be a lot<br>
of bug reports by people unfamiliar with the technology and hence<br>
unable to debug. Since a lot of problems will be caused by bad device<br>
implementations we should get as much info about the local UPnP<br>
environment as possible.<br>
For this we can create a data-gathering application, probably using<br>
python, that will help us developers hugely by reducing the required<br>
skill level of the UPnP bug-reporters.<br></blockquote><div><br>During or after the GSoC?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Clearly this needs access to some UPnP devices in a testing lab<br>
setting as well as some experience with an established UPnP framework<br>
different then the backend KDE is using.</blockquote><div><br>Here we have quite time researching about UPnP stuff and access to many devices for testing. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
After all, we can't rule out<br>
library bugs when we use the same one for gathering the debug data.<br>
Some packaging experience will help as well, it should be an easy to<br>
use, preferably self-contained binary or self-installable script with<br>
a simple UI and a direct upload function to <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a>.<br></blockquote><div><br>If the use of HUPnP has become a requirement for the development of the backend, we can use <a href="http://brisa.garage.maemo.org/">our
framework</a> to the tests.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
Bart<br>
</font></blockquote></div><br>