Re: [Kde-hardware-devel] Solid UPnP GSoC idea
2010/4/7 Friedrich W. H. Kossebau kosse...@kde.org: Hi Bart, Paulo and all, Mardi, le 6 avril 2010, à 13:46, Bart Cerneels a écrit: Hey metalworkers, The recent discussion here and on melange have shown that UPnP is a Melange? http://socghop.appspot.com/ 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 This proposal focuses on the Solid detection side and also various smaller integrations into KDE SC. Examples I can think of: - Plasma device notifier extended to list UPnP mediaserver shares. 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. A module wrapping access to the InternetGatewayDevice type would indeed be useful. E.g. currently KTorrent and Konversation both have their own custom stand-alone code (though derived from each other) to punch a hole into the gateway (for NAT traversal), and Kopete lacks even that. Don't forget KNetworkManager and solid-network. Getting info about your internet gateway is useful for all sorts of reasons like security (hole punching permission?), automatic settings based on gateway (proxy, static IP override, automount network shares, etc) and I'm sure there are a lot more possible use-cases. - Network neighborhood plasma widget. I would like that. And other like Kevin I also think it should be a different one to the one for the locally connected. I even would prefer it it would show the devices similarly to how the windows are shown in the tasks(/windows) applet, just with icon-only mode. Kind of what the network:/ kio-slave shows, just as convenient applet, with added value. The UPnP backend for Solid will test the architecture in preparation for other local network protocols: DAAP, Bonjour, netbios, ... For this it might also be interesting to see how http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/network/network/ could be enhanced as an alternative. The remote (and more service-oriented) nature of stuff on the network might not really fit into the scope of Solid perhaps. Unless we expect Solid to e.g. deliver all http servers on the network. Would we? Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
2010/4/7 Kevin Ottens er...@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 ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
2010/4/8 Bart Cerneels bart.cerne...@kde.org 2010/4/7 Kevin Ottens er...@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 ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[Kde-hardware-devel] RFC: Integration of Cagibi, a SSDP cache/proxy daemon (proposed part of UPnP support)
Hi, (followups please only on kde-core-devel) you may know that there has been some activity to open the world of UPnP to KDEs software. Stuff in the UPnP world, that may be services like MediaServers for most of you, serving collections of media files (see [MS] for a list). Recently support to both Solid and the network:/ kio-slave has been added in trunk to list also list UPnP devices/services (see [US]). This was done by code connecting to Coherence [CP] via D-Bus, thus introducing an optional runtime dependency. Just, Coherence has a big footprint (10,7 MiB unshared memory shown in System Activity), which is for sure too much for the simple thing it is currently used for by both the Solid backend and the network:/ kio-slave, namely a SSDP (Simple Service Discovery Protocol) cache/proxy daemon. Compare this to avahi-daemon with just 176 kiB unshared memory, doing something similar. So I hacked up a little Qt-only daemon named Cagibi [CA] for that purpose, to be interfaced with D-Bus. Not perfect with 424 kiB unshared memory, but a start. It's now up to a first release 0.1 and works nicely for the local ports of the Solid backend and the network:/ kio-slave I have done. While it still is under discussion if Cagibi is a proper part of the KDE Platform's wrapping of the UPnP world, I think it is and would like to get things done and improved. The GSoC candidate to work on an UPnP MediaServer kio-slave is interested, too. So I would like to move Cagibi to kdesupport, as it might be interesting also to software built on other frameworks (like Avahi is to all). And also do releases from there, so I could commit the ports of the Solid backend and the network:/ kio-slave. Would I have to pass kdereview? I guess no. Who is in charge of kdesupport? Or would I just move the code over from playground? Comments, flames, chocolate? [MS] http://www.upnp-database.info/listDevices.jsp?filterType=servers [US] http://frinring.wordpress.com/2010/02/25/metalworks-for-upnp-devices-at- tokamak4/ [CP] http://coherence-project.org/ [CA] http://websvn.kde.org/trunk/playground/network/cagibi/ Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[Kde-hardware-devel] UPnP support on OS X/Windows
Hi Armijn and all, once upon a time you gave principal UPnP support in the KDE platform that more and more famous draft: http://www.mail-archive.com/kde-hardware-devel@kde.org/msg00358.html With Cagibi*, the SSDP cache/proxy daemon I'm hacking on, there is now something like that broker you envisioned in that draft arising, D-Bus interface developed in an agile style. HUPnP might serve as the base for the UPnP profile specific client libraries/modules, like the MediaServer kio-slave. No real idea about the eventing yet. But with kdelibs trying multi-platform I wonder: Can you tell how UPnP support on Windows and OS X is done? Both UI wise and API wise? Is this part of the platform or offered by a favourite add-on? How would we connect to that? UI: I heard UPnP devices are listed in the Windows Explorer. On click it opens a browser pointing to the presentation url. Is this only done with the root device, or also for all embedded ones (which can have presentation urls, too)? API: ? * First release of Cagibi is in the door, see separate email. Cheers Friedrich -- KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
Hello, On Wednesday 7 April 2010 20:25:19 Paulo Rômulo wrote: After reading your messages I have written my early proposal for this idea and before submit it at the GSoC website, I would listen some feedback from you. You can find it here: http://docs.google.com/View?id=d785g6k_11gpccrpdx In short: I think that some more work is required for this proposal. And really sorry about this opinion as we're definitely cutting it very short to the deadline so you don't have much time to research on the different topics. Now some more details: - I think you can safely add the data-gathering application to the GSoC proposal itself as I think a couple of points are overestimated. - InternetGatewayDevice wrapper module comes directly from Friedrich mail without further details. What do you have in mind there? In fact I think it could simply be one new frontend class in libsolid and would then mostly be part of the Solid UPnP backend work. Once you got the backend rolling it should be fairly trivial. - I think that the Plasma Device Notifier is overestimated in the timeline... - ... while the Network Neighborhood Plasmoid is likely underestimated. - Overall, more details on each of the tasks would be welcome. It'd show that you indeed know what work is required. - For the details regarding solid itself, hunt me down to get details. But apart from those missing details, a mockup for the Network Neighborhood Plasmoid would be very welcome. I'll be around on IRC tomorrow (from 6am to 5pm UTC) if you have more questions about solid itself (and I bet you do have such questions). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
On Thursday 8 April 2010 14:47:03 Paulo Rômulo wrote: 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? I'd say during. There's likely enough time for it IMO (depends how fast the solid backend would be ready, but the other proposed tasks aren't that large). 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, Well, I can't really judge which one is the best (ambiguous metric, hey?) between HUPnP and Brisa. But from the discussions here, it seems that HUPnP is the one with most momentum right now and then the most likely to be accepted. we can use our framework http://brisa.garage.maemo.org/ to the tests. Sounds like a good idea, in particular since you could use the python version which seems more mature and would allow fast prototyping of said tool. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
On Wednesday 7 April 2010 15:01:51 Friedrich W. H. Kossebau wrote: A module wrapping access to the InternetGatewayDevice type would indeed be useful. E.g. currently KTorrent and Konversation both have their own custom stand-alone code (though derived from each other) to punch a hole into the gateway (for NAT traversal), and Kopete lacks even that. Not sure what you have in mind here with module. But the way I see it, the only thing required would be a Solid::NetworkGateway class (inheriting from DeviceInterface) which would provide two methods (one to open a port, one to close it). This way once you get a hold on a device which is IGD you could just: Solid::Device d = ...; d.asSolid::NetworkGateway()-openPort(...); ... d.asSolid::NetworkGateway()-closePort(...); Sounds fairly easy to use from any application out there. - Network neighborhood plasma widget. I would like that. And other like Kevin I also think it should be a different one to the one for the locally connected. I even would prefer it it would show the devices similarly to how the windows are shown in the tasks(/windows) applet, just with icon-only mode. Kind of what the network:/ kio-slave shows, just as convenient applet, with added value. In fact, wouldn't it be a specialized view on network:/ results? Sounds very much like it to me. The UPnP backend for Solid will test the architecture in preparation for other local network protocols: DAAP, Bonjour, netbios, ... For this it might also be interesting to see how http://websvn.kde.org/trunk/KDE/kdebase/runtime/kioslave/network/network/ could be enhanced as an alternative. The remote (and more service-oriented) nature of stuff on the network might not really fit into the scope of Solid perhaps. Unless we expect Solid to e.g. deliver all http servers on the network. Would we? I'd say no. That'd definitely be opening the pandora box. :-) I think we should limit ourselves to multimedia devices/network storage (just like we used to report media players... but now they're connected via ethernet/wifi and not simply USB) and to those very focused headless devices (network gateway, possibly home automation devices). http server lacks some focus I'd say. We shouldn't simply report anything which has a port open to the outside. ;-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Solid UPnP GSoC idea
On Thursday 8 April 2010 12:12:04 Bart Cerneels wrote: 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. Well, as far as libsolid is concerned obviously no need for such an abstraction. Who would want to abstract the abstraction that libsolid is? ;-) We can have several different UPnP backends in there, some being built or not depending on the platform (to ensure using the native facilities if needed). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
