[upnp-sdk-dev] release 1.3.1, rpm, ixmlPrintDocument

[John D. <jd...@re...>]

First of all Remi, thank you for your work and releasing version 1.3.1.
I've downloaded it and did some testing. I also reviewed the work you
did to convert building with automake, libtool, pkgconfig etc. It looks
excellent and is a huge improvement!

Eric, I was not aware you had done an RPM for extras, thank you. Back in
January, which is when I looked, it was not there, it looks like you
added it in the interim. Now that Remi has released 1.3.1 we'll need to
update the rpm to use it. Because of the work Remi did supporting the
standard build/packaging tools the spec file will need some rework.
Fortunately it should get simpler :-) Do you want to do this or would
you like me to? I ask because I'm not sure how familiar you are with
spec files which utilize this build/install paradigm. 

On the issue of installation, I see that the libraries for threadutil
and ixml are installed in the system in parallel with upnp. I wonder if
in the long run that's a good idea. These two libraries I imagine are
only ever going to be used by upnp, there are probably better
independent libraries for threads and xml and we probably don't want
folks independently using and linking against these two libraries in the
belief they are supported interfaces. At some point it might be
worthwhile to link these libraries into libupnp and hide their symbols.

Remi, I do have a fix which needs to be folded in, I wish I had known
you were about to prepare a release so we didn't have to respin again.
Here is the issue:

The problem is only evident with devices and only if the device uses the
UpnpRegisterRootDevice2 entry point. It appears as if the SDK authors
realized that UpnpRegisterRootDevice was simplistic and inflexible and
added UpnpRegisterRootDevice2 later in development. Perhaps at some
point these two functions could be collapsed into one.

With UpnpRegisterRootDevice2 it is possible to generate the device
description document dynamically and have the internal web server serve
an in-memory copy of the document as opposed to a file. This is actually
a very useful technique and ixmlPrintDocument is the means to get an
in-memory copy of the XML description document given a DOM tree. Just
one problem. ixmlPrintDocument does not produce a valid XML document
because it leaves out the XML document prolog. I discovered this when
testing with control points based on Microsoft Windows UPnP framework.
The Microsoft implementation will silently ignore any UPnP devices whose
description document is malformed and that includes omitting the XML
prolog.

In the UPnP SDK ixmlPrintDocument had been #define'd to be ixmlPrintNode
which prints XML elements. The fix I believe is to have to independent
functions, ixmlPrintDocument and ixmlPrintNode (same for the toString
versions) where the Document functions include the prolog and the Node
functions omit it. The attached patch (which I'll also post on the SF
site) creates the new Document functions which prepends the prolog and
replaces every instance of ixmlPrintDocument with ixmlPrintNode because
the two are now no longer interchangeable (except in configure_urlbase()
in the file urlconfig.c, because here you do want a document).

I imagine the reason neither of you ran into this problem is because
you've been doing control point code and not device code.

This is an interface change and as such the libtool versioning will have
to be bumped. BTW, the patch is against the 1.3.1 version.

-- 
John Dennis <jd...@re...>
Red Hat Inc.