[Kde-hardware-devel] Solid UPnP GSoC idea

[Paulo Rômulo]

2010/4/8 Bart Cerneels <bart.cerneels at kde.org>

> 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.
>

During or after the GSoC?


> 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.


Here we have quite time researching about UPnP stuff and access to many
devices for testing.

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.
>

If the use of HUPnP has become a requirement for the development of the
backend, we can use our framework <http://brisa.garage.maemo.org/> to the
tests.


>
> Bart
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100408/456ecdc0/attachment.htm