Menu
▾
▴
upnp-sdk-dev — Discussion of development related issues with the UPnP SDK
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(9) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John D. <jd...@re...> - 2006-04-06 20:46:49
|
Michael, while from the outside it would appear as the project is dead, it isn't. I agree it's a bit hard to figure out what is going on from the public pages, but with a little digging you'll discover work is being done. Many kudo's are due to R=C3=A9mi Turboult who has stepped up = to the plate and recently made a new release. R=C3=A9mi has also made a numb= er of fixes and added GNU autotool support. Eric Tanguy has also contributed an RPM. There is more work which needs to be done and I'm sure your contributions will be welcome. To the best of my knowledge Red Hat is going to start shipping the libupnp SDK and we have an engineer assigned to that task. This is not an official announcement from us, just a friendly indicator of interest in the SDK. The libupnp SDK is alive and hopefully will be getting more exposure. --=20 John Dennis <jd...@re...> Red Hat Inc. |
|
From: <qx...@gm...> - 2006-04-04 05:49:52
|
> The project was inactive not for lack of interest by the maintainers, > but > lack of interest from the community. For years, no one was really > willing to > contribute anything nor was anyone interested in taking over the > project. I think most developers will leave the project pages when they see the "This page was last updated on: 13-Feb-2003" or at least when they realize that the home page is really outdated - there a version 1.2.1 is listed while 1.3.1 is the latest one. What do you think how many developers try to join or help the project under these circumstances? The rest of them will be discouraged when they see the bugtracker with its open bugs or the patch-tracker - 10 of 15 submissions are open. Of course I don't blame you on that but in my opinion all these signs are good reasons for the poor state of the project. > If you wish to take over as the (or a) maintainer of the project, let me > know and I can add you. I would like to see this project continue to > flourish. It is just unfortunate that I do not have the time to > contribute to this project. I'd be glad to help you with the project - or at least try it. I'll send you a private email about that. Michael > > - Dan - > > -----Original Message----- > From: upn...@li... > [mailto:upn...@li...] On Behalf Of qx...@gm... > Sent: Monday, April 03, 2006 3:25 AM > To: upn...@li...; > upn...@li... > Subject: [upnp-sdk-dev] Project UPnP is DEAD > > Not very funny what I can see... > > - the homepage at upnp.sf.net is totally outdated, not only the latest > release isn't mentioned there > > - the maintainers seem to be not interested in the project, the bugtracker > is full of open bugs > > - patches and modifications that are sent in by developers are ignored, > nothing new is integrated > > So I'd not be astonished if there are also no maintainers active within > the > mailing lists. For me that means the project is dead, apparently because > of > the lack of interest of the maintainers while developers are willing and > able to contribute to the project. > > Also if I won't expect to get an answer: what plans are there with the > future of the libupnp? > > Mike > > > -- > Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! > Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Upnp-sdk-dev mailing list > Upn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > UPnP-SDK-discuss mailing list > UPn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-discuss > -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl |
|
From: Dan B. <dba...@us...> - 2006-04-04 05:30:34
|
Why should you be surprised if the maintainers are still active? How did you get subscribed to the SDK dev mailing list if there are no maintainers? The project was inactive not for lack of interest by the maintainers, but lack of interest from the community. For years, no one was really willing to contribute anything nor was anyone interested in taking over the project. Those of us who started the project have been waiting to see if any interest kindled in the project. Only in the last couple of months has some interest sparked. As for developer interest, I've been monitoring the mailing lists from day one. Other than Remi and John of late, there hasn't been much developer interest. I haven't seen much email with patches or queries about getting involved. Had I seen that, I would have responded. If you wish to take over as the (or a) maintainer of the project, let me know and I can add you. I would like to see this project continue to flourish. It is just unfortunate that I do not have the time to contribute to this project. - Dan - -----Original Message----- From: upn...@li... [mailto:upn...@li...] On Behalf Of qx...@gm... Sent: Monday, April 03, 2006 3:25 AM To: upn...@li...; upn...@li... Subject: [upnp-sdk-dev] Project UPnP is DEAD Not very funny what I can see... - the homepage at upnp.sf.net is totally outdated, not only the latest release isn't mentioned there - the maintainers seem to be not interested in the project, the bugtracker is full of open bugs - patches and modifications that are sent in by developers are ignored, nothing new is integrated So I'd not be astonished if there are also no maintainers active within the mailing lists. For me that means the project is dead, apparently because of the lack of interest of the maintainers while developers are willing and able to contribute to the project. Also if I won't expect to get an answer: what plans are there with the future of the libupnp? Mike -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Upnp-sdk-dev mailing list Upn...@li... https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev |
|
From: <tur...@ea...> - 2006-04-03 20:17:48
|
Michael, > I made some modifications with the code to get the libupnp compilable und= er > Solaris 9, complete porting will be the next step. > > But now my question is how I can contribute the code to the project - who > can I send the modifications so that they can be integrated? I suggest you create a new tracker item (patch), attaching the diff,=20 preferably against the latest CVS. If I have some time, I will integrate it (else someone else will do it). I= =20 don't have the test infrastructure though, so you will have to contribute=20 some testing. Best regards, R=E9mi |
|
From: <tur...@ea...> - 2006-04-03 20:02:21
|
Hello, > The only thing that appears to be missing is the documentation > and sample programs. These should probably go > in /usr/share/doc/libupnp-* > > I don't think auto generated doc is terribly important, it would be nice > but not critical, but I do think including UPnP_Programming_Guide.pdf is > essential. > I have added the documentation stuff (--with-docdir as you suggested , but= =20 also --without-docdir works if you need to skip doc install). Most of it is in the CVS (I can't add the rest now because it is down). I also put back the UPnP_Programming_Guide.pdf from the libupnp-doc-1.2.1=20 package, because the one in the CVS seemed corrupted. > (Note: examples_DATA probably also needs a Makefile utilizing > pkg-config) not done yet ... =2D-=20 R=E9mi |
|
From: <qx...@gm...> - 2006-04-03 10:25:24
|
Not very funny what I can see... - the homepage at upnp.sf.net is totally outdated, not only the latest release isn't mentioned there - the maintainers seem to be not interested in the project, the bugtracker is full of open bugs - patches and modifications that are sent in by developers are ignored, nothing new is integrated So I'd not be astonished if there are also no maintainers active within the mailing lists. For me that means the project is dead, apparently because of the lack of interest of the maintainers while developers are willing and able to contribute to the project. Also if I won't expect to get an answer: what plans are there with the future of the libupnp? Mike -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer |
|
From: <qx...@gm...> - 2006-04-01 15:57:05
|
Hi, I made some modifications with the code to get the libupnp compilable under Solaris 9, complete porting will be the next step. But now my question is how I can contribute the code to the project - who can I send the modifications so that they can be integrated? Kind regards Michael -- E-Mails und Internet immer und überall! 1&1 PocketWeb, perfekt mit GMX: http://www.gmx.net/de/go/pocketweb |
|
From: Xu D. J. \(R&D S. D. S. T. S. Engineer\) <ja...@20...> - 2006-03-20 02:57:54
|
aGkgYWxsDQogDQogICAgSSBhbSB0cnlpbmcgdG8gY3Jvc3MgY29tcGlsZSBsaWJ1cG5wLTEuMi4x IGZvciBhIGRldmljZSBydW5uaW5nIGFybSBwcm9jZXNzb3IgDQogDQp3aXRoIHVjbGludXguIEhh dmUgYW55b25lIGJlZW4gc3VjY2Vzc2Z1bCB0byBmaW5pc2ggaXQ/DQogDQogICAgaWYgeWVzLCBj b3VsZCBhbnlvbmUgbGV0IG1lIGtub3cgaG93IGNvdWxkIHlvdSBmaW5pc2ggaXQ/Pw0KIA0KIA0K ICAgdGhhbmtzIGZvciB5b3VyIGhlbHAsDQogDQogICBCZXN0IHJlZ2FyZA0KIA0KICAgSmFtZXMN Cg== |
|
From: John D. <jd...@re...> - 2006-03-15 19:55:14
|
On Thu, 2006-03-09 at 23:02 +0100, R=C3=A9mi wrote: > John, >=20 > > 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 loo= ks > > excellent and is a huge improvement! > > =20 > thanks ! >=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. (...) > > At some point it might be > > worthwhile to link these libraries into libupnp and hide their symbol= s. > > =20 > except that ixml has its own documented interface (see the libupnp-doc=20 > package), and normally is used directly by programs interfacing with=20 > libupnp.I think it would not be practical to hide it. May be merge it,=20 > but that would break programs linking with the 3 libraries. Good points, sounds fine to me. >=20 > > > > In the UPnP SDK ixmlPrintDocument had been #define'd to be ixmlPrintN= ode > > which prints XML elements. The fix I believe is to have to independen= t > > functions, ixmlPrintDocument and ixmlPrintNode (same for the toString > > versions) where the Document functions include the prolog and the Nod= e > > functions omit it. The attached patch (which I'll also post on the SF > > site) creates the new Document functions which prepends the prolog an= d > > replaces every instance of ixmlPrintDocument with ixmlPrintNode becau= se > > the two are now no longer interchangeable (except in configure_urlbas= e() > > in the file urlconfig.c, because here you do want a document). > > =20 > you are right, that's the way ixmlPrintDocument should have been=20 > implemented from the beginning. However, I have seen programs using thi= s=20 > existing interface as it is, and manually adding the prolog. > This fix would silently break this interface. To keep backward=20 > compatibility : wouldn't it be preferable to add a new function (e.g.=20 > ixmlPrintDocumentWithProlog or something like that), and document the=20 > deficiency in the old function? >=20 > Also : another user suggests to implement a check in the libupnp, in=20 > order to add the prolog in the device description document if it is=20 > missing : > =20 > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D931724&gro= up_id=3D7189&atid=3D107189 > I don't know if this other patch is correct or not, but we could=20 > implement this idea too, in addition the the ixml fix. >=20 > What's your view ? I'm not much in favor of codifying broken behavior or per user implementation of hacks. I would much prefer to see the library work cleanly out of the box. I don't think the libupnp SDK is in such wide spread use yet that fear of breaking previous usage justifies retaining buggy behavior and thus forcing new users of the library to learn the work-around, surely a time waste for them (as it was for me). I believe a new release could draw attention via release notes and/or a message on the download page about the change in behavior and thus accommodate the earlier adopters. Also, I've cc'ed Jason Vas Dias on this email. Jason sits near me here at Red Hat and it looks like he is going to pick up ownership of this package. Jason tells me there has been some discussion of moving libupnp into core from extras, but I'll leave that discussion to Eric and Jason to pursue. Also, as a side note, I've implemented a few upnp programs using the SDK. I started with the TV samples whose coding style I found a bit awkward and in the process rewrote and reformatted much of the samples. It also includes new utilities to set search criteria, handle command line input, etc. If anyone is interested I'm happy to donate the code. --=20 John Dennis <jd...@re...> Red Hat Inc. |
|
From: <tur...@ea...> - 2006-03-09 22:07:53
|
John, > 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 y= ou > did to convert building with automake, libtool, pkgconfig etc. It l= ooks > excellent and is a huge improvement! > =20 thanks ! > On the issue of installation, I see that the libraries for threadut= il > and ixml are installed in the system in parallel with upnp. I wonde= r if > in the long run that's a good idea. (...) > At some point it might be > worthwhile to link these libraries into libupnp and hide their symb= ols. > =20 except that ixml has its own documented interface (see the libupnp-do= c=20 package), and normally is used directly by programs interfacing with= =20 libupnp.I think it would not be practical to hide it. May be merge it= ,=20 but that would break programs linking with the 3 libraries. > > In the UPnP SDK ixmlPrintDocument had been #define'd to be ixmlPrin= tNode > which prints XML elements. The fix I believe is to have to independ= ent > functions, ixmlPrintDocument and ixmlPrintNode (same for the toStri= ng > versions) where the Document functions include the prolog and the N= ode > 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 bec= ause > the two are now no longer interchangeable (except in configure_urlb= ase() > in the file urlconfig.c, because here you do want a document). > =20 you are right, that's the way ixmlPrintDocument should have been=20 implemented from the beginning. However, I have seen programs using t= his=20 existing interface as it is, and manually adding the prolog. This fix would silently break this interface. To keep backward=20 compatibility : wouldn't it be preferable to add a new function (e.g.= =20 ixmlPrintDocumentWithProlog or something like that), and document the= =20 deficiency in the old function? Also : another user suggests to implement a check in the libupnp, in= =20 order to add the prolog in the device description document if it is= =20 missing : =20 http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D931724&g= roup_id=3D7189&atid=3D107189 I don't know if this other patch is correct or not, but we could=20 implement this idea too, in addition the the ixml fix. What's your view ? R=E9mi |
|
From: <r3...@us...> - 2006-03-09 21:36:45
|
Eric Tanguy wrote:
> What do you think about this R=C3=A9mi ?
> =20
that it'll have to wait until after 20th March, when I am back :-)
Regards,
R=C3=A9mi
|
|
From: Eric T. <eri...@un...> - 2006-03-09 17:50:49
|
Le mardi 07 mars 2006 =C3=A0 18:17 -0500, John Dennis a =C3=A9crit :
> On Tue, 2006-03-07 at 22:42 +0100, Eric Tanguy wrote:
> > 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 t=
he
> > package or submit a patch, don't hesitate! The only thing is that thi=
s
> > 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
> Excellent Eric! You're one step ahead of me again. The rpm looks
> fabulous. The only thing that appears to be missing is the documentatio=
n
> and sample programs. These should probably go
> in /usr/share/doc/libupnp-*
>=20
> I don't think auto generated doc is terribly important, it would be nic=
e
> but not critical, but I do think including UPnP_Programming_Guide.pdf i=
s
> essential.=20
>=20
> Off the top of my head without any testing (I feel like I'm going to
> regret my caviler suggestions which weren't tested :-) Something like
> this should do the trick (Remi: since these seem to be tweaks to the
> configure stuff perhaps it should be added at your end, or you may
> prefer a different approach):
>=20
> % in configure.ac add:
>=20
> AC_ARG_WITH([docdir], AC_HELP_STRING([--with-docdir=3DDIR],
> [where documentation is installed]),
> [docdir=3D"$with_docdir"],
> [docdir=3D"${datadir}/doc/${PACKAGE_NAME}-${PACKAGE_VERSION=
}"])
>=20
> AC_SUBST(docdir)
>=20
> % in upnp/doc/Makefile.am add:
>=20
> docdir =3D @DOCDIR@
> doc_DATA =3D UPnP_Programming_Guide.pdf
>=20
> % in upnp/Makefile.am add:
>=20
> docdir =3D @DOCDIR@
> examplesdir =3D $(docdir)/examples
> examples_DATA =3D $(upnp_tv_ctrlpt_SOURCES) $(upnp_tv_device_SOURCES)
>=20
> (Note: examples_DATA probably also needs a Makefile utilizing
> pkg-config)
>=20
> Once all this is done Eric then I think all that needs to be done is to
> just add the doc files to the %files section in the spec file.
>=20
> If either of you prefers I do the work I'm happy to.
>=20
> With respect to moving libupnp from extras to core that's a decision
> which will be out there in the future a bit. At the moment our use of
> this technology is experimental and not yet fundamental to the core
> product (all of which is subject to change :-)
>=20
Ok but i prefer to wait this will be included directly in the tarball. Wh=
at do you think about this R=C3=A9mi ?
Cheers, Eric
|
|
From: John D. <jd...@re...> - 2006-03-07 23:17:38
|
On Tue, 2006-03-07 at 22:42 +0100, Eric Tanguy wrote:
> 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 ?
Excellent Eric! You're one step ahead of me again. The rpm looks
fabulous. The only thing that appears to be missing is the documentation
and sample programs. These should probably go
in /usr/share/doc/libupnp-*
I don't think auto generated doc is terribly important, it would be nice
but not critical, but I do think including UPnP_Programming_Guide.pdf is
essential.
Off the top of my head without any testing (I feel like I'm going to
regret my caviler suggestions which weren't tested :-) Something like
this should do the trick (Remi: since these seem to be tweaks to the
configure stuff perhaps it should be added at your end, or you may
prefer a different approach):
% in configure.ac add:
AC_ARG_WITH([docdir], AC_HELP_STRING([--with-docdir=DIR],
[where documentation is installed]),
[docdir="$with_docdir"],
[docdir="${datadir}/doc/${PACKAGE_NAME}-${PACKAGE_VERSION}"])
AC_SUBST(docdir)
% in upnp/doc/Makefile.am add:
docdir = @DOCDIR@
doc_DATA = UPnP_Programming_Guide.pdf
% in upnp/Makefile.am add:
docdir = @DOCDIR@
examplesdir = $(docdir)/examples
examples_DATA = $(upnp_tv_ctrlpt_SOURCES) $(upnp_tv_device_SOURCES)
(Note: examples_DATA probably also needs a Makefile utilizing
pkg-config)
Once all this is done Eric then I think all that needs to be done is to
just add the doc files to the %files section in the spec file.
If either of you prefers I do the work I'm happy to.
With respect to moving libupnp from extras to core that's a decision
which will be out there in the future a bit. At the moment our use of
this technology is experimental and not yet fundamental to the core
product (all of which is subject to change :-)
--
John Dennis <jd...@re...>
Red Hat Inc.
|
|
From: Eric T. <eri...@un...> - 2006-03-07 21:43:01
|
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 |
|
From: John D. <jd...@re...> - 2006-03-07 20:46:37
|
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. |
|
From: UPnP T. <pu...@pr...> - 2005-10-15 15:23:54
|
mPuf 2.3 New features - glib main loop integration for Linux (this makes GTK+ applications easily UPnP enabled) - download section now also provide Linux binary version cross compiled for ARM - sample for GTK+ based control point. jPuf 2.1 New features - GUI control panel including UCP, code generator, UPnP testing tool - Ability to write OSGi based control points Full featured evaluation could be downloaded from http://www.protosys.com/download.htm For developer documentation please refer to http://www.protosys.com/developers.htm Best Regards UPnP Team About mPuf mPuf is a highly optimized UPnP 1.0 specification implementation. It is completely implemented in C and implements GENA, SSDP, SOAP, a micro Web Server and a micro XML parser. About jPuf jPuf is java implementation of UPnP in unique container approach. About Sphinx 1.0 UPnP solution for Symbian |
|
From: <tur...@ea...> - 2005-10-13 18:42:41
|
Has someone already ported libupnp to use GNU automake and autoconf ? |
|
From: <tur...@ea...> - 2005-10-13 18:42:36
|
Is libupnp actively maintained ? And is there plan for future releases ? I have some patches against libupnp 1.2.1a : can they be considered for inclusion ? |
|
From: Bass8tt8 <bas...@li...> - 2005-08-31 15:06:55
|
HI,
i'm trying to compile Upnp SDK for Linux to ECOS OS !
I have varius errors :
1 )
...linking FreeList.o LinkedList.o TimerThread.o config.o iasnprintf.o =
main.o sample_util.o upnp_tv_device.o upnpapi.o upnptools.o =
D:/Documenti/TESI/UpnpSDK/libupnp-1.2.1/upnp/bin/libupnp.so: =
could not read symbols: Invalid operation
I can't link libupnp.so, libixml.so and libthreadutil.so , what do =
include these libraries ?
2) I can't understand the scope of definition of DBGONLY ( .... =
UpnpPrintf (...) );
During compilation i have a lot of error like this :: =20
d:/Ultimodule/DeviceStudio/workspace/UpnpTest/upnpapi.c(.text.UpnpFinish+=
0x154): undefined reference to `UpnpPrintf'
and i don't understand why...
thanks Michele
|
|
From: <mar...@fr...> - 2005-07-17 16:09:46
|
Hi everybody, Did anyone had ever seen the problem that if the IP address of your devic= e is given hardly (not by a DHCP server) UpnpInit fails and gives the -208 ock= et error. I had already had this problem once and when I gave the ip address by DHC= P the problem was solved! Does anyone know why? Is that absolutely necessay tha= t the device obtain it's ip address by DHCP server? Thanks by advance, Maryam |
|
From: <tur...@ea...> - 2005-07-13 16:23:38
|
I encountered the same problem when browsing large media collections : the maxiumum size of UPnP messages set in the library is exceeded (default is 16KB, maximum settable is 32 KB, which might be insufficient when browsing large A/V collections). I had to patch the upnp library : see my "djmount" project at : https://sourceforge.net/projects/djmount/ This project allows to mount as a Linux filesystem the content of MediaServer devices compatible with the UPnP AV protocol. It has been tested ok with the TwonkyVision UPnP Music Server. This is alpha code. It includes a patched libupnp. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Bandan D. <ba...@zo...> - 2005-07-13 05:37:38
|
Hi!
I am trying to implement a upnp control point for a twonky vision media server
running on linux. After retriving the device name, control URL and all, i
try to browse the Content Directory using the "Browse" action using the
following:
-------------------------------------------------------------------------------------------------------
printf("Making XML file to send action\n");
actionNode=UpnpMakeActionFile("Browse",
"urn:schemas-upnp-org:service:ContentDirectory:1",0 ,NULL);
rc=UpnpSendActionAsync(ctrlpt_handle,
"http://192.168.1.23:9001/ContentDirectory.xml",
"urn:schemas-upnp-org:service:ContentDirectory:1", NULL, actionNode,
CallBackEventHandler, NULL);
-----------------------------------------------------------------------------------------------------------
Then I use the struct upnp_action_request to check the result of the action
in
case UPNP_CONTROL_ACTION_COMPLETE. When I check the error code in ErrCode I
find it to be -113 which means that the response received from the remote
side is not correct for the protocol.
Can anyone please figure out where the error is?
Thanks
Bandan
|
|
From: Bandan D. <ba...@zo...> - 2005-07-09 13:43:52
|
Hi! I would like to design a upnp AV control point that would browse for Media Servers and display a list of media content. Getting the list of servers is easy. But how do I use the server's Content Directory Service to browse for the files that are available on it? Thanks Bandan |
|
From: Bandan D. <ba...@zo...> - 2005-07-09 05:58:38
|
Hi! I am trying to cross compile libupnp-1.2.1 for a device running arm processor with uclinux. For this I first source the paths required by issuing the following command : source $DIR/path.sh and then run : cd libupnp-1.2.1/upnp make TARGET=arm-elf I get a lot of error messages about undefined reference as below : ----------------------------------------------------------------------------------------------------------- obj/arm-elf/ixml.o: In function `copy_with_escape': obj/arm-elf/ixml.o(.text+0x24): undefined reference to `strlen' obj/arm-elf/ixml.o: In function `ixmlParseBufferEx': obj/arm-elf/ixml.o(.text+0x830): undefined reference to `strlen' obj/arm-elf/ixml.o: In function `ixmlCloneDOMString': obj/arm-elf/ixml.o(.text+0x898): undefined reference to `strdup' obj/arm-elf/ixml.o: In function `ixmlFreeDOMString': obj/arm-elf/ixml.o(.text+0x8b4): undefined reference to `free' obj/arm-elf/node.o: In function `ixmlNode_init': obj/arm-elf/node.o(.text+0x14): undefined reference to `memset' obj/arm-elf/node.o: In function `ixmlCDATASection_init': obj/arm-elf/node.o(.text+0x30): undefined reference to `memset' obj/arm-elf/node.o: In function `ixmlNode_freeSingleNode': obj/arm-elf/node.o(.text+0x74): undefined reference to `free' obj/arm-elf/node.o(.text+0x84): undefined reference to `free' obj/arm-elf/node.o(.text+0x94): undefined reference to `free' obj/arm-elf/node.o(.text+0xa4): undefined reference to `free' obj/arm-elf/node.o(.text+0xb4): undefined reference to `free' obj/arm-elf/node.o(.text+0xc8): more undefined references to `free' follow obj/arm-elf/node.o: In function `ixmlNode_setNamespaceURI': ------------------------------------------------------------------------------------------------------------ Can anyone help me out with this? Ofcourse I have been able to cross compile other applications using the other method. Thanks Bandan |
|
From: Claudio T. <ckt...@gm...> - 2005-03-21 12:47:33
|
Hi Folks, I am not able to run UPnP applications over bluetooth in debian linux O.S. The bluetooth stack is BlueZ. Does anyone working with this stuff? I am trying run the app sample, tvdevice and tv control point, downloaded from http://upnp.sourceforge.net/ The sample runs only over ethernet network! If I disable eth0 interface and try run the tv device setting the bluetooth interface(bnep0) the miniserver initialization fails. The function to get the ssdp socket fails! Who knows how fix this problem? Thanks, Claudio. |
