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

[Nikhil Marathe]

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.

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 :)

Nikhil