[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

[Friedrich W. H. Kossebau]

Samedi, le 27 mars 2010, à 18:48, Nikhil Marathe a écrit:
> On Fri, Mar 26, 2010 at 3:23 PM, Will Stephenson <wstephenson at kde.org> 
wrote:
> > Apart from these basic requirements, what upcoming features of HUpnp will
> > you depend upon and how would it affect your proposal if HUpnp feature
> > development slows down?
> 
> It's unlikely that we will require much more than what Hupnp already
> provides, which is a control point, service discovery and action
> invocation mechanisms. That said, Coherence still remains the first
> choice because it is much more mature, and has proved interop with
> other devices. My main gripe is that Coherence does not seem to allow
> action invocations over D-BUS, ie. they always fail with a timeout.
> Now this may be purely my problem.
> 
> That said, using Coherence might mean that the upnp features may not
> work out of the box, since I don't think it is a wise idea to make a
> large library, written in Python and having quite a lot of
> dependencies, a core dependency for kdelibs/kdebase.
> 
> I'll be sticking to Coherence, as soon as I can get action invocation
> going on some device via D-BUS. The current kioslave or solid backend
> don't seem to do this either.

Sadly I haven't been much successful so far at this during some private 
experiments, neither. All D-Bus calls just hang or time out.
But I just reported this by email to the main developer, did not create a 
ticket for that.
 
> But Hupnp does remain something to watch out for, especially if it
> stabilises and development is steady. A C++ lib using Qt signals and
> slots is IMHO much nicer than talking over D-BUS :)

+1

Perhaps might also be faster and less overhead to the system to talk directly 
to the devices, without going over a broker.

Cheers
Friedrich
-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta