Re: [Kde-hardware-devel] Solid UPnP GSoC idea
Mercredi, le 7 avril 2010, à 04:24, Nikhil Marathe a écrit: 2010/4/7 Kevin Ottens er...@kde.org: On Tuesday 6 April 2010 13:46:02 Bart Cerneels wrote: 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. Well, no longer (hopefully). As written in the other email I have done a prototype for a SSDP cache/proxy named Cagibi and also a port of the Solid UPnP backend to it. So HUPnP is an option IMHO. I would really like Friedrich's opinion on the framework since he has some work done already and I wouldn't like to drop all that unless there are technical merits to do so. Wouldn't welcome that, too ;) The reason I am sticking to HUPnP while experimenting is that it provides a much more Qt like API rather than interpreting DBus output. There are of course certain edge cases and special devices which might be handled better in Coherence, since they have been actively working on this. It is stated explicitly on their homepage about support for devices which don't comply completely to the spec, but I haven't looked at their code so much except for the D-BUS part. From my (very limited) point of view I see more value in using HUPnP (or a similar Qt-based lib, talking generally :) ) in the long run, so there is not much duplication on disk and memory (Qt/KDE libs vs. Python stuff for the same problems like network access etc.). And compiled code might be faster. Coherence might be a good solution now as it seems be hardened by real life exposure. So: we can learn from their code :) But remember I do not really have much practical knowledge about UPnP (usage), my background is more the general device/service listing (as in the network: kio-slave). 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
On Wed, Apr 7, 2010 at 6:01 PM, Friedrich W. H. Kossebau kosse...@kde.org wrote: Mercredi, le 7 avril 2010, à 04:24, Nikhil Marathe a écrit: 2010/4/7 Kevin Ottens er...@kde.org: On Tuesday 6 April 2010 13:46:02 Bart Cerneels wrote: 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. Well, no longer (hopefully). As written in the other email I have done a prototype for a SSDP cache/proxy named Cagibi and also a port of the Solid UPnP backend to it. I will checkout Cagibi. If it is doing discovery well, then I think sticking to that for system-wide discovery is good. From my (very limited) point of view I see more value in using HUPnP (or a similar Qt-based lib, talking generally :) ) in the long run, so there is not much duplication on disk and memory (Qt/KDE libs vs. Python stuff for the same problems like network access etc.). And compiled code might be faster. Coherence might be a good solution now as it seems be hardened by real life exposure. So: we can learn from their code :) Yes, HUPnP can then be used by the services which actually require device interaction, and not just those which list the devices. I suppose Cagibi could be extended to report the UPnP device type ( I haven't looked at the code yet, so I have no idea what it does ) Remark: Doing a very unscientific benchmark of using System Activity, my simple HUPnP based kio-slave was taking ~6mb of unshared memory. -Nikhil ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
