2010/4/8 Bart Cerneels <[email protected]> > 2010/4/7 Kevin Ottens <[email protected]>: > > 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 >
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
