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

[Eric T. <eri...@un...>]

Le mardi 07 mars 2006 =C3=A0 15:46 -0500, John Dennis a =C3=A9crit :
> 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!
>=20
> Eric, I was not aware you had done an RPM for extras, thank you. Back i=
n
> 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.=20

John, the rpms for release 1.3.1 are already built for FC-3, FC-4 and
devel as well as new version of ushare using it. If you want to own the
package or submit a patch, don't hesitate! The only thing is that this
lib have to be compliant with ushare (the package which need it and
that's why i did rpm for libupnp). Another question : redhat will
include it in core or prefer to let it in extras ?

>=20
> 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 th=
e
> belief they are supported interfaces. At some point it might be
> worthwhile to link these libraries into libupnp and hide their symbols.
>=20
> 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:
>=20
> The problem is only evident with devices and only if the device uses th=
e
> 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.
>=20
> 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 actuall=
y
> 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 whos=
e
> description document is malformed and that includes omitting the XML
> prolog.
>=20
> In the UPnP SDK ixmlPrintDocument had been #define'd to be ixmlPrintNod=
e
> 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).
>=20
> I imagine the reason neither of you ran into this problem is because
> you've been doing control point code and not device code.
>=20
> This is an interface change and as such the libtool versioning will hav=
e
> to be bumped. BTW, the patch is against the 1.3.1 version.
>=20