Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves

Friedrich W. H. Kossebau kossebau at
Wed Jun 29 00:08:16 BST 2011


too bad noone was up to push it finally into kde-runtime when it was ready for 
it, but let's pick it up again now:

Mardi, le 26 avril 2011, à 14:53, Nikhil Marathe a écrit:
> Hi,
> KDE SC 4.7 soft feature freeze is close, and I would like to propose
> the UPnP MediaServer KIO slave
> ( be
> included into the set of kio slaves shipped with kde-runtime. The
> slave was created as part of GSoC 2010 - Amarok and KDE UPnP support
> and it was decided that it should be merged into kde-runtime at some
> point.
> A couple of reasons I believe the slave is now ready for standard release
> is: 1) HUpnp ( - the Qt based UPnP library used
> by the slave has a stable API and ABI with the release of 1.0.0 about 3
> weeks ago.
> 2) The slave has been considerably simplified and single threaded, and
> stable now.
> 3) The slave is independent and can be conditionally compiled and
> installed if HUpnp is installed. kdelibs already contains a
> FindHUpnp.cmake to find the HUpnp library.
> 4) The Solid UPnP backend (enabled in 4.7, again if HUpnp is found)
> automatically launches UPnP media servers in the file manager with the
> slave.
4b) And that Places integration of 4) will be useless if there is no upnp-ms 
kio-slave, people would click on the mediaserver icon but see nothing in the 
5) It is also used by Amarok since 2.4.0 (if found)
6) It adds no further dependencies than there are with kdelibs (i.e. HUpnp as 
optional library, if not found the kio-slave will be simply skipped). So UPnP 
support in Solid is aligned with kio-upnp-ms here.

> My exams get over this week and I can ensure that krazy checks pass
> and the code is cleaned up some more.

But then Nikhil had his job life interfering, so could not spend any time on 
pushing this request forward :(
I did a short code review, looked fine (could not comment on HUPnP usage, but 
who can besides Nikhil?), and some code optimization patches I did even got 
merged by Nikhil meanwhile.

> There is inline documentation where required, and the search and
> browse API documentation exists. There is no user
> manual since it is a slave. I am confident about having it ready by
> hard feature freeze.

I also would consider it ready for first serious usage. After all it will 
enable all KIO-enabled programs to access the media content on UPnP media 
servers out there (e.g. Xbox), at least to a certain degree.

So, release-team, what would you think about an exception to still include the 
upnp-ms kio-slave in kde-runtime 4.7? After all it was ready, just noone 
replied to him besides Kevin and me both saying "Keep it coming!".
It does not affect any other code, as it is an isolated kio-slave. Might not 
even be compiled if some distro has not yet HUpnp packages. But if there are 
HUpnp packages the Places integration (Dolphin/filedialog) for UPnP media 
servers will be useless without this kio-slave. So distros would have to 
install this kio-slave anyway. So it might make sense to have the kio-slave 
already in kde-runtime, instead of extragear, where I would like to push it 
otherwise, so it can be released together with the SC 4.7 officially and 
distros know about this additional feature/kio-slave.

If you say No (understandable):
What is the process to make the playground/base repo of kio-upnp-ms an 
extragear/base repo in times of git repos? Could not find it documented on 
techbase, pointers welcome.
And how would that repo be marked that it should be included in the SC 4.7 
release process?

If you say Yes (would be welcome):
Tomorrow/Today evening (wednesday, 29 june) I would see to create a branch 
from kde-runtime master where the commit history of the kio-upnp-ms repo is 
merged (been there, done that), have that reviewed by someone and then 
backport that merge to 4.7 branch. Okay?

Desktop Summit 2011 in Berlin - Registered already? -

More information about the kde-core-devel mailing list