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

Armijn Hemel armijn at uulug.nl
Tue Mar 30 14:01:22 CEST 2010


hi!

> 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.

I would not say that right away. Although UPnP does seem simple at first
sight there is quite a bit more to it when you want to go for a full
implementation and Coherence is much much better at this right now.

One thing is that there are many incredibly dumb UPnP implementations
out there that don't parse the XML that is used in the protocol, but do
simple string comparisons. If the XML does not match with what Windows
XP sends (namespaces and all that) you are out of luck. I encountered
this problem with many VxWorks based machines, like the Linksys WRT54Gv5
and later.

There is also the fact that you might want to send received device
announcements to many programs at once, especially in a multiseat
desktop. I am not sure how well that can be done with Qt and slots, to
have one system wide daemon running and sending signals to multiple
programs of multiple users at once.

Another thing that you are currently overlooking is eventing (HTTP
callbacks and all that). I must admit, this is hardly ever used, but it
adds a lot of complexity if you want to make a complete UPnP
implementation. One option would be to ignore eventing completely ;-)

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

See above, I'm not entirely sure it is.

Now, some completely (not entirely unrelated) unrelated things.

In real life I have encountered only a few profiles. Internet Gateway
Device is of course still a very important one. Right now there are a
few client implementations in KDE. From the top of my head, I think some
work was done in Kopete and Ktorrent, but both implementations were
quite barebones.

MediaServer and MediaPlayer are quite common these days. I would advise
against implementing MediaPlayer in Amarok, unless you want people to be
able to remotely control your Amarok (I would not want that). Supporting
MediaServer is a very obvious thing to do. Everyone would love that. The
hardest part (I think) would be to get searching right. There are
various flavours: 1.0 and 2.0. If you want to go for DLNA stick with
1.0.

A protocol I am seeing sometimes is the new WPA2 setup stuff as pushed
by the WifiAlliance, where the exchange for WPA2 keys is done via UPnP,
if the machine and router are connected via wires.

Another UPnP implementation that I sometimes encounter is RemoteUI.
Controlling it would be fun, but it is not installed on my devices.

What I've heard is that the HVAC-profile is actually in use, but I have
never encountered those IRL (I guess HVACs are also more of an American
thing).

As others said: integrating control point functionality into Amarok for
just MediaServer should already be more than enough of a challenge ;-)

armijn

-- 
-------------------------------------------------------------------------
armijn at uulug.nl | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group
-------------------------------------------------------------------------



More information about the Kde-hardware-devel mailing list