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

[Armijn Hemel]

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.
> 
> That is not relevant for this project. We are working with
> MediaServers which, thanks to DLNA, have become very standardized and
> predictable. Also these implementations certainly don't run on
> crippled RTOS'es.

Yes, well, but routers that people have might run it. It was meant as a
small reminder :-)

> > 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.
> 
> The only limiting factor there can be the broadcast address+port used
> by UPnP (239.255.255.250:1900) will be reserved. Unless some IPC
> system is limits the simultaneous use of 2 UPnP clients. The rest of
> the stack runs independent, with some redundant work being done,
> although extremely minimal.

Multicast 239.255.255.250:1900 should be used for both sending and
receiving. Or, to be more exact: you should listen on the same port on
which you send messages, as well as multicast to 239.255.255.250:1900

> >> 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.
> 
> Regardless of personal preference, there is very serious interest for
> that in our userbase. Important to note is that a good implementation
> of DMR (the DLNA name for UPnP MediaRender) will request user
> permission before being controlled.

*cringe*

Ah well, as long as it can be disabled :-P

> > 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).
> 
> Some proposed protocols are just that, proposals. These for instance
> don't have an implementation or there is just no interest.
> In general, if it's not covered by DLNA don't seriously consider
> implementing it.

Internet Gateway Device? :-P

>  it just happens that some remote UI use cases are
> covered in the latest DLNA requirements (August 2009) though. So we
> might start seeing this pop up.

Is that using the RemoteUI profile?

> There are also printing scenarios in DLNA, perhaps we should support
> those as well, or by proxy via CUPS. Probably a bit harder since KDE
> doesn't have it's own printing system anymore.

Sounds like a nice GSoC for CUPS ;-)

armijn

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