[Kde-hardware-devel] Solid UPnP GSoC idea

[Nikhil Marathe]

On Wed, Apr 7, 2010 at 6:01 PM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Mercredi, le 7 avril 2010, à 04:24, Nikhil Marathe a écrit:
>> 2010/4/7 Kevin Ottens <ervin at 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