[Kde-hardware-devel] Solid UPnP GSoC idea

[Friedrich W. H. Kossebau]

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.

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