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: Hartwig D. <har...@gm...> - 2006-04-26 14:52:28
|
2006/4/26, qxc@ <qx...@gm...>... > > there is one big problem with this change: the current variant offers an > easy way to port the library to other operation systems that do NOT use > the > pthreads-thingy (like Windows). > > Currently the adaption has to be done in ithreads.h only, using this > change > developers have to modify the code everywhere. > Hi, I do not agree with this argument. libupnp currently depends on posix threads functionality, renaming functions from pthread_xxx to ithread_xxx does nothing to change this. No additional functionality is provided by the ithread header!! Hence, the fact that libupnp requires posix threads (and uses its data-structures) is hidden, which is IMHO a bad thing. If libupnp was using actually using a portable threads library, it would be a completely different story. Once somebody decides to port libupnp to a platform without posix threads, the functionality of the required subset of pthreads has to be provided for that platform. Why not implement it as a separate library, preferrably called libpthread and providing a header pthread.h (it could still be distributed with the libupnp source code, but at least for me, this seems like an independent task)? BTW, there is a pthread library for win32, see http://sourceware.org/pthreads-win32/, so no need to worry about windows. BTW, there is something else to consider about these patches: projects usin= g libupnp might have to be changed, if they use ithread.h, thus this is a user-visible API change (checked with gmediaserver, which does use this header, if only in a few places). Hartwig |
|
From: <qx...@gm...> - 2006-04-26 07:11:06
|
Hi, there is one big problem with this change: the current variant offers an easy way to port the library to other operation systems that do NOT use the pthreads-thingy (like Windows). Currently the adaption has to be done in ithreads.h only, using this change developers have to modify the code everywhere. Michael > --- Ursprüngliche Nachricht --- > Von: "Hartwig Deneke" <har...@gm...> > An: upn...@li... > Betreff: [upnp-sdk-dev] Patches: Remove ithread.h header and change users > over to pthreads > Datum: Tue, 25 Apr 2006 22:35:41 +0200 > > Dear Developers, > > I have just uploaded two patches to the patches section, which remove the > file ithreads.h and change all users to directly include <pthreads.h> and > its functions instead. ithreads.h did not provide any functionality but > just > re-defined the "pthread_" prefix to "ithread_". Hence I think it does not > provide any benefits and only hides that libupnp uses posix threads.If you > consider this change usefull, please apply, > Cheers, > Hartwig > -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: Hartwig D. <har...@gm...> - 2006-04-25 20:35:48
|
Dear Developers, I have just uploaded two patches to the patches section, which remove the file ithreads.h and change all users to directly include <pthreads.h> and its functions instead. ithreads.h did not provide any functionality but jus= t re-defined the "pthread_" prefix to "ithread_". Hence I think it does not provide any benefits and only hides that libupnp uses posix threads.If you consider this change usefull, please apply, Cheers, Hartwig |
|
From: Peter E. <sf...@en...> - 2006-04-24 23:04:40
|
|
From: Peter E. <sf...@en...> - 2006-04-24 22:57:51
|
As a caveat to my other comments; I have a fair background in=20 programming but am an absolute n00b on Linux so I've been on a rather=20 steep learning curve so far! R=E9mi wrote: > On Saturday 22 April 2006 07:44, Peter Enzerink wrote: > =20 >> I have just posted a patch for 64 bit file support. It includes a >> change to upnp.h which affects programmes using the library. This is >> necessary because both the file length and offset needed to be >> increased in File_Info. >> =20 > > thanks, this is good news ! > The patch looks good, I have some comments below. > > Also : your patch corrects only the server half (webserver parts).=20 > Needs to be done as well : the client download functions (Upnp*HttpGet*= ) : are=20 > you willing to address this as well ? > =20 I hadn't looked at the client but will do so. >> Well almost! The filesize is handled properly by the browser interface >> but CDS is suddenly bombing. >> =20 > > which CDS ? > > Best regards,=20 > R=E9mi > =20 It was just one of a number of areas where the return type was too=20 small. The soap code had more of them. I believe they have all been=20 fixed in the server code. > -----------------------------------------------------------------------= ------ > > - general : avoid including generated files (Makefile.in) in the patch,= it=20 > becomes difficult to read > =20 Ah yep. > - don't forget to patch the ChangeLog as well > =20 I didn't want to make this an official change until people more=20 knowledgeable than me could provide feedback. >> diff -Naur libupnp/upnp/Makefile.am libupnp-1.3.1/upnp/Makefile.am >> --- libupnp/upnp/Makefile.am 2006-03-06 07:31:17.000000000 +1100 >> +++ libupnp-1.3.1/upnp/Makefile.am 2006-03-20 11:39:09.000000000 +1100 >> @@ -9,7 +9,7 @@ >> >> AM_CPPFLAGS =3D -I$(srcdir)/inc \ >> -I$(top_srcdir)/threadutil/inc \ >> - -I$(top_srcdir)/ixml/inc >> + -I$(top_srcdir)/ixml/inc -D__USE_FILE_OFFSET64 >> >> =20 > =20 > hmm. This shouldn't be necessary : the AC_SYS_LARGEFILE check I already= put in=20 > configure.ac normally sets in a portable way all the needed flags for=20 > largefile offsets (see generated autoconfig.h : _FILE_OFFSET_BITS,=20 > _LARGEFILE_SOURCE ...). In particular with glibc, __USE_FILE_OFFSET64 i= s=20 > automatically set if _FILE_OFFSET_BITS is set to 64. > Did you have problems without this ? > =20 I could be wrong but I think that diff was in the CVS version of the=20 code. If it isn't then it probably isn't required anyway. Cheers |
|
From: <tur...@ea...> - 2006-04-24 20:58:03
|
in addition to my previous remarks, I saw one important problem : the use of "off_t" in exported headers (upnp.h) : this will generate= =20 problems, for example if a shared libupnp is compiled with 64 bits of= f_t=20 (--enable-largefile, the default), but a program using it uses 32bits= =20 offsets. For a more lengthy description and several solutions see her= e :=20 http://ac-archive.sourceforge.net/largefile/index.html The simplest solution is to use our own new type in the API (e.g.= =20 typedef long long Upnp_Offset) and program accordingly in the=20 implementation (e.g. before calling seeko, check that the intended= =20 offset can be represented in off_t, in case the library has been=20 compiled with 32bits offsets). Another solution is to use off_t in the API, and check that a program= =20 using it is compiled in the same mode as was the library. Best regards, R=E9mi |
|
From: <tur...@ea...> - 2006-04-24 20:22:51
|
qx...@gm... wrote: > Where can I find that changelog? > it is the ChangeLog file at the top of the "libupnp" source tree. R=E9mi |
|
From: <rem...@m4...> - 2006-04-24 20:19:47
|
qx...@gm... wrote: > Where can I find that changelog? > > =20 it is the ChangeLog file at the top of the "libupnp" source tree. R=E9mi |
|
From: <tur...@ea...> - 2006-04-24 20:16:37
|
qx...@gm... wrote: > I found out that there is a CVS-branch named "djmount". That seems = to belong > to an completely different project so my question is why is it ther= e and > what is its purpose within the project UPnP? > =20 I created the branch when I imported the libupnp that I maintained= =20 previously within djmount. Now that the import is done (it was before libupnp 1.3.0) it has no= =20 longer any use. R=E9mi |
|
From: <qx...@gm...> - 2006-04-24 06:39:18
|
Where can I find that changelog? > --- Ursprüngliche Nachricht --- > Von: Rémi <tur...@ea...> > An: upn...@li... > Kopie: vir...@gm... > Betreff: Re: [upnp-sdk-dev] undocumented changes > Datum: Sun, 23 Apr 2006 15:13:47 +0200 > > Hello, > > > I just noticed that changes have been commited to the libupnp CVS, but > the > > ChangeLog file has not been updated. I think it is mandatory, in a > > multi-developper enviroenement, to update this file for every change, > else > > there is no simple way to track all that happens. > > Can the respective commiters update the file for the last changes ? > > again : can the developpers update the ChangeLog for the changes commited > (solaris, printdocument, ...) ? > > > Best regards, > Rémi > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: <qx...@gm...> - 2006-04-24 06:38:53
|
Hi, I found out that there is a CVS-branch named "djmount". That seems to belong to an completely different project so my question is why is it there and what is its purpose within the project UPnP? Michael -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner |
|
From: <tur...@ea...> - 2006-04-23 13:14:13
|
Hello, > I just noticed that changes have been commited to the libupnp CVS, but the > ChangeLog file has not been updated. I think it is mandatory, in a > multi-developper enviroenement, to update this file for every change, else > there is no simple way to track all that happens. > Can the respective commiters update the file for the last changes ? again : can the developpers update the ChangeLog for the changes commited=20 (solaris, printdocument, ...) ? Best regards,=20 R=E9mi |
|
From: <tur...@ea...> - 2006-04-23 13:04:40
|
On Saturday 22 April 2006 07:44, Peter Enzerink wrote: > I have just posted a patch for 64 bit file support. It includes a > change to upnp.h which affects programmes using the library. This is > necessary because both the file length and offset needed to be > increased in File_Info. thanks, this is good news ! The patch looks good, I have some comments below. Also : your patch corrects only the server half (webserver parts).=20 Needs to be done as well : the client download functions (Upnp*HttpGet*) : = are=20 you willing to address this as well ? > Well almost! The filesize is handled properly by the browser interface > but CDS is suddenly bombing. which CDS ? Best regards,=20 R=E9mi =2D------------------------------------------------------------------------= =2D--- =2D general : avoid including generated files (Makefile.in) in the patch, i= t=20 becomes difficult to read =2D don't forget to patch the ChangeLog as well > diff -Naur libupnp/upnp/Makefile.am libupnp-1.3.1/upnp/Makefile.am > --- libupnp/upnp/Makefile.am 2006-03-06 07:31:17.000000000 +1100 > +++ libupnp-1.3.1/upnp/Makefile.am 2006-03-20 11:39:09.000000000 +1100 > @@ -9,7 +9,7 @@ >=20 > AM_CPPFLAGS =3D -I$(srcdir)/inc \ > -I$(top_srcdir)/threadutil/inc \ > - -I$(top_srcdir)/ixml/inc > + -I$(top_srcdir)/ixml/inc -D__USE_FILE_OFFSET64 >=20 =20 hmm. This shouldn't be necessary : the AC_SYS_LARGEFILE check I already put= in=20 configure.ac normally sets in a portable way all the needed flags for=20 largefile offsets (see generated autoconfig.h : _FILE_OFFSET_BITS,=20 _LARGEFILE_SOURCE ...). In particular with glibc, __USE_FILE_OFFSET64 is=20 automatically set if _FILE_OFFSET_BITS is set to 64. Did you have problems without this ? |
|
From: Peter E. <sf...@en...> - 2006-04-22 06:43:14
|
Peter Enzerink wrote: > Howdy. > > I am very keen to be involved in this project. > > I have just posted a patch for 64 bit file support. It includes a > change to upnp.h which affects programmes using the library. This is > necessary because both the file length and offset needed to be > increased in File_Info. > > These patches in conjunction with some related patches to ushare now > allows me to stream ISOs. > > Cheers Well almost! The filesize is handled properly by the browser interface but CDS is suddenly bombing. I'll keep at it as I'm obviously close to cracking this. Cheers |
|
From: Peter E. <sf...@en...> - 2006-04-21 12:56:28
|
Howdy. I am very keen to be involved in this project. I have just posted a patch for 64 bit file support. It includes a change to upnp.h which affects programmes using the library. This is necessary because both the file length and offset needed to be increased in File_Info. These patches in conjunction with some related patches to ushare now allows me to stream ISOs. Cheers |
|
From: <qx...@gm...> - 2006-04-16 10:42:08
|
Dan, to make one thing clear: I think nobody wants to blame you personally, if somebody has no time to maintain a free project thats not a personal shame for that person! What I did not realized until now is that you want to give it away completely. My intention to create a fork of the project simply was the fact that when I'd be the mainly only person that contributes to the project and/or manages it I also could it do for myself completely. But thats nothing I stated for now, I wanted to watch how things are going on and decide MUCH later. So if you are really willing to give the project away it of course would not make any sense to create a fork, to split the activites and make both projects more weak, in this case I'd be glad to take over the maintainership for it. Michael > --- Ursprüngliche Nachricht --- > Von: "Dan Baumberger" <dba...@us...> > An: <qx...@gm...>, "'Nektarios K. Papadopoulos'" > <npa...@in...> > Kopie: <upn...@li...> > Betreff: RE: [upnp-sdk-dev] Project UPnP is DEAD > Datum: Sat, 15 Apr 2006 22:47:16 -0700 > > I am a little confused by this whole thread. This project started in 2001 > and generated little development interest from anybody until late in 2005. > After years of not seeing anything really going on, I stopped monitoring > the > project (other than the mailing lists) because I did not have the time. > Our > intentions when creating this project were not to be the maintainers for > the > long term but to find someone willing and able to take over. > Unfortunately, > that person (or persons) never turned up. We contacted a few people that > might be interested over the years but were turned down. > > In the last few months, we have received several "threats" about forking > the > project. My question to you is why don't you (in the plural sense) step up > and take over this one instead of creating confusion by forking the > project? > If you have the time and interest to take over the project, I am more than > willing to pass it on. The intention never was to ignore anybody's > contributions but with little time and no one to help, it was inevitable. > > Let me know if this is something you would like to do. It only takes a few > clicks of the mouse to pass on the torch. > > - Dan - > > -----Original Message----- > From: upn...@li... > [mailto:upn...@li...] On Behalf Of qx...@gm... > Sent: Saturday, April 15, 2006 5:45 AM > To: Nektarios K. Papadopoulos > Cc: upn...@li... > Subject: Re: [upnp-sdk-dev] Project UPnP is DEAD > > Hi, > > the worst thing behind these ancient patches: there also has been one of a > RedHat developer, that means the project had a contribution from a > developer > of the probably most important Linux distribution and ignored it. > > What I completely don't understand is why these patches are ignored for > that > long time. Applying one to the current CVS mostly isn't a big problem but > if > they are that old like most of them it becomes nearly impossible to do > that. > > And I think thats the best way of demotivating developers and people that > want to help: waiting until their work becomes useless... > > Michael > > PS: Currently I'm a developer within the UPNP project but depending on the > progress that the project makes I'm still thinking about a fork from it > where the contributions and efforts other people make are more respected. > > > > > --- Ursprüngliche Nachricht --- > > Von: "Nektarios K. Papadopoulos" <npa...@in...> > > An: upn...@li... > > Betreff: Re: [upnp-sdk-dev] Project UPnP is DEAD > > Datum: Fri, 14 Apr 2006 10:46:06 +0300 > > > > Hi Dan, > > > > I've been using upnp-sdk for the last 12 months so I've to thank the > > creators/maintainers for this. Congrats! > > > > OTOH, I've been subscribed to the mailing lists for the same amount of > > time and I'm sorry to say that before 1.3.1 came out, I had the same > > feeling with Mike. > > > > The list of open patches/bugs that goes back a few years is certainly > > giving that impression. I've submitted three of them myself and I've to > > say that when I did I was thinking "I don't expect anyone to see > > this...". 2 of them got closed with 1.3.1 release. > > > > When I saw the 1.3.1 announcement, I was totally surprised. The 1.3.0 > > released just one day before, was never announced. There was no > > discussion on the list about the plans, no pre-release for us to test > etc. > > > > I mean, even Remi's queries "Is libupnp maintained ?" and "automake and > > autoconf for libupnp ?" back in Oct 13 2005 remained unanswered in the > > dev list. Obviously, they were answered/discussed privately but this > > does not help to attract more developers. > > > > I think you could have been more clear about "help wanted"; as you just > > did ;-) > > So, I'd like to help with the project anyway I can (when time permits). > > > > BR, > > Nektarios > > > > Dan Baumberger wrote: > > > 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 > > > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > -- > 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 > > -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl |
|
From: Nektarios K. P. <npa...@in...> - 2006-04-16 08:41:49
|
As far as I am concerned this thread is *not* about blaming you or the=20 rest of the UPnP team. So there is no need to defend yourself. :-) My intention was to step up and say "Hey something is not going very well with this project!" "I care about this project" "I want to help improving the image" I've never threaten to fork the project. I don't even want to take over the project (I don't have the time). I=20 honestly believe it takes more than a few clicks of the mouse to pass on=20 the torch. I mean you can not transfer accumulated knowledge and=20 experience by clicking the mouse ;-) But: I am willing to help. I can be part of a community that actively maintains the project. I can go through the patches/bug reports and discuss them here in the=20 dev list. I see Remi is already doing this, but I can help. -- Nektarios Dan Baumberger wrote: > I am a little confused by this whole thread. This project started in 20= 01 > and generated little development interest from anybody until late in 20= 05. > After years of not seeing anything really going on, I stopped monitorin= g the > project (other than the mailing lists) because I did not have the time.= Our > intentions when creating this project were not to be the maintainers fo= r the > long term but to find someone willing and able to take over. Unfortunat= ely, > that person (or persons) never turned up. We contacted a few people tha= t > might be interested over the years but were turned down. >=20 > In the last few months, we have received several "threats" about forkin= g the > project. My question to you is why don't you (in the plural sense) step= up > and take over this one instead of creating confusion by forking the pro= ject? > If you have the time and interest to take over the project, I am more t= han > willing to pass it on. The intention never was to ignore anybody's > contributions but with little time and no one to help, it was inevitabl= e. >=20 > Let me know if this is something you would like to do. It only takes a = few > clicks of the mouse to pass on the torch. >=20 > - Dan - >=20 > -----Original Message----- > From: upn...@li... > [mailto:upn...@li...] On Behalf Of qxc@gmx.= de > Sent: Saturday, April 15, 2006 5:45 AM > To: Nektarios K. Papadopoulos > Cc: upn...@li... > Subject: Re: [upnp-sdk-dev] Project UPnP is DEAD >=20 > Hi, >=20 > the worst thing behind these ancient patches: there also has been one o= f a > RedHat developer, that means the project had a contribution from a deve= loper > of the probably most important Linux distribution and ignored it. >=20 > What I completely don't understand is why these patches are ignored for= that > long time. Applying one to the current CVS mostly isn't a big problem b= ut if > they are that old like most of them it becomes nearly impossible to do = that. >=20 > And I think thats the best way of demotivating developers and people th= at > want to help: waiting until their work becomes useless... >=20 > Michael >=20 > PS: Currently I'm a developer within the UPNP project but depending on = the > progress that the project makes I'm still thinking about a fork from it > where the contributions and efforts other people make are more respecte= d. >=20 >=20 >=20 >> --- Urspr=FCngliche Nachricht --- >> Von: "Nektarios K. Papadopoulos" <npa...@in...> >> An: upn...@li... >> Betreff: Re: [upnp-sdk-dev] Project UPnP is DEAD >> Datum: Fri, 14 Apr 2006 10:46:06 +0300 >> >> Hi Dan, >> >> I've been using upnp-sdk for the last 12 months so I've to thank the=20 >> creators/maintainers for this. Congrats! >> >> OTOH, I've been subscribed to the mailing lists for the same amount of= =20 >> time and I'm sorry to say that before 1.3.1 came out, I had the same=20 >> feeling with Mike. >> >> The list of open patches/bugs that goes back a few years is certainly=20 >> giving that impression. I've submitted three of them myself and I've t= o=20 >> say that when I did I was thinking "I don't expect anyone to see=20 >> this...". 2 of them got closed with 1.3.1 release. >> >> When I saw the 1.3.1 announcement, I was totally surprised. The 1.3.0=20 >> released just one day before, was never announced. There was no=20 >> discussion on the list about the plans, no pre-release for us to test = etc. >> >> I mean, even Remi's queries "Is libupnp maintained ?" and "automake an= d=20 >> autoconf for libupnp ?" back in Oct 13 2005 remained unanswered in the= =20 >> dev list. Obviously, they were answered/discussed privately but this=20 >> does not help to attract more developers. >> >> I think you could have been more clear about "help wanted"; as you jus= t=20 >> did ;-) >> So, I'd like to help with the project anyway I can (when time permits). >> >> BR, >> Nektarios >> >> Dan Baumberger wrote: >>> 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 maintainer= s? >>> >>> 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.=20 >>> >>> As for developer interest, I've been monitoring the mailing lists fro= m >> day >>> one. Other than Remi and John of late, there hasn't been much develop= er >>> interest. I haven't seen much email with patches or queries about >> getting >>> involved. Had I seen that, I would have responded.=20 >>> >>> 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 lates= t >>> 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 ignore= d, >>> nothing new is integrated >>> >>> So I'd not be astonished if there are also no maintainers active with= in >> the >>> mailing lists. For me that means the project is dead, apparently beca= use >> 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 th= e >>> future of the libupnp? >>> >>> Mike >>> >>> >> >> >> ------------------------------------------------------- >> 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=3Dlnk&kid=3D110944&bid=3D241720&da= t=3D121642 >> _______________________________________________ >> Upnp-sdk-dev mailing list >> Upn...@li... >> https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev >> >=20 |
|
From: Dan B. <dba...@us...> - 2006-04-16 05:47:27
|
I am a little confused by this whole thread. This project started in = 2001 and generated little development interest from anybody until late in = 2005. After years of not seeing anything really going on, I stopped monitoring = the project (other than the mailing lists) because I did not have the time. = Our intentions when creating this project were not to be the maintainers for = the long term but to find someone willing and able to take over. = Unfortunately, that person (or persons) never turned up. We contacted a few people that might be interested over the years but were turned down. In the last few months, we have received several "threats" about forking = the project. My question to you is why don't you (in the plural sense) step = up and take over this one instead of creating confusion by forking the = project? If you have the time and interest to take over the project, I am more = than willing to pass it on. The intention never was to ignore anybody's contributions but with little time and no one to help, it was = inevitable. Let me know if this is something you would like to do. It only takes a = few clicks of the mouse to pass on the torch. - Dan - -----Original Message----- From: upn...@li... [mailto:upn...@li...] On Behalf Of = qx...@gm... Sent: Saturday, April 15, 2006 5:45 AM To: Nektarios K. Papadopoulos Cc: upn...@li... Subject: Re: [upnp-sdk-dev] Project UPnP is DEAD Hi, the worst thing behind these ancient patches: there also has been one of = a RedHat developer, that means the project had a contribution from a = developer of the probably most important Linux distribution and ignored it. What I completely don't understand is why these patches are ignored for = that long time. Applying one to the current CVS mostly isn't a big problem = but if they are that old like most of them it becomes nearly impossible to do = that. And I think thats the best way of demotivating developers and people = that want to help: waiting until their work becomes useless... Michael PS: Currently I'm a developer within the UPNP project but depending on = the progress that the project makes I'm still thinking about a fork from it where the contributions and efforts other people make are more = respected. > --- Urspr=FCngliche Nachricht --- > Von: "Nektarios K. Papadopoulos" <npa...@in...> > An: upn...@li... > Betreff: Re: [upnp-sdk-dev] Project UPnP is DEAD > Datum: Fri, 14 Apr 2006 10:46:06 +0300 >=20 > Hi Dan, >=20 > I've been using upnp-sdk for the last 12 months so I've to thank the=20 > creators/maintainers for this. Congrats! >=20 > OTOH, I've been subscribed to the mailing lists for the same amount of = > time and I'm sorry to say that before 1.3.1 came out, I had the same=20 > feeling with Mike. >=20 > The list of open patches/bugs that goes back a few years is certainly=20 > giving that impression. I've submitted three of them myself and I've = to=20 > say that when I did I was thinking "I don't expect anyone to see=20 > this...". 2 of them got closed with 1.3.1 release. >=20 > When I saw the 1.3.1 announcement, I was totally surprised. The 1.3.0=20 > released just one day before, was never announced. There was no=20 > discussion on the list about the plans, no pre-release for us to test = etc. >=20 > I mean, even Remi's queries "Is libupnp maintained ?" and "automake = and=20 > autoconf for libupnp ?" back in Oct 13 2005 remained unanswered in the = > dev list. Obviously, they were answered/discussed privately but this=20 > does not help to attract more developers. >=20 > I think you could have been more clear about "help wanted"; as you = just=20 > did ;-) > So, I'd like to help with the project anyway I can (when time = permits). >=20 > BR, > Nektarios >=20 > Dan Baumberger wrote: > > 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? > >=20 > > 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.=20 > >=20 > > 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.=20 > >=20 > > 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. > >=20 > > - Dan - > >=20 > > -----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 > >=20 > > Not very funny what I can see... > >=20 > > - the homepage at upnp.sf.net is totally outdated, not only the = latest > > release isn't mentioned there > >=20 > > - the maintainers seem to be not interested in the project, the > bugtracker > > is full of open bugs > >=20 > > - patches and modifications that are sent in by developers are = ignored, > > nothing new is integrated > >=20 > > 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. > >=20 > > Also if I won't expect to get an answer: what plans are there with = the > > future of the libupnp? > >=20 > > Mike > >=20 > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dlnk&kid=3D110944&bid=3D241720&dat=3D= 121642 > _______________________________________________ > Upnp-sdk-dev mailing list > Upn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev >=20 --=20 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=3Dlnk&kid=3D110944&bid=3D241720&dat=3D= 121642 _______________________________________________ Upnp-sdk-dev mailing list Upn...@li... https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev |
|
From: <qx...@gm...> - 2006-04-15 12:45:26
|
Hi, the worst thing behind these ancient patches: there also has been one of a RedHat developer, that means the project had a contribution from a developer of the probably most important Linux distribution and ignored it. What I completely don't understand is why these patches are ignored for that long time. Applying one to the current CVS mostly isn't a big problem but if they are that old like most of them it becomes nearly impossible to do that. And I think thats the best way of demotivating developers and people that want to help: waiting until their work becomes useless... Michael PS: Currently I'm a developer within the UPNP project but depending on the progress that the project makes I'm still thinking about a fork from it where the contributions and efforts other people make are more respected. > --- Ursprüngliche Nachricht --- > Von: "Nektarios K. Papadopoulos" <npa...@in...> > An: upn...@li... > Betreff: Re: [upnp-sdk-dev] Project UPnP is DEAD > Datum: Fri, 14 Apr 2006 10:46:06 +0300 > > Hi Dan, > > I've been using upnp-sdk for the last 12 months so I've to thank the > creators/maintainers for this. Congrats! > > OTOH, I've been subscribed to the mailing lists for the same amount of > time and I'm sorry to say that before 1.3.1 came out, I had the same > feeling with Mike. > > The list of open patches/bugs that goes back a few years is certainly > giving that impression. I've submitted three of them myself and I've to > say that when I did I was thinking "I don't expect anyone to see > this...". 2 of them got closed with 1.3.1 release. > > When I saw the 1.3.1 announcement, I was totally surprised. The 1.3.0 > released just one day before, was never announced. There was no > discussion on the list about the plans, no pre-release for us to test etc. > > I mean, even Remi's queries "Is libupnp maintained ?" and "automake and > autoconf for libupnp ?" back in Oct 13 2005 remained unanswered in the > dev list. Obviously, they were answered/discussed privately but this > does not help to attract more developers. > > I think you could have been more clear about "help wanted"; as you just > did ;-) > So, I'd like to help with the project anyway I can (when time permits). > > BR, > Nektarios > > Dan Baumberger wrote: > > 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 > > > > > > > > ------------------------------------------------------- > 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 > -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer |
|
From: Nektarios K. P. <npa...@in...> - 2006-04-14 07:46:52
|
Hi Dan, I've been using upnp-sdk for the last 12 months so I've to thank the creators/maintainers for this. Congrats! OTOH, I've been subscribed to the mailing lists for the same amount of time and I'm sorry to say that before 1.3.1 came out, I had the same feeling with Mike. The list of open patches/bugs that goes back a few years is certainly giving that impression. I've submitted three of them myself and I've to say that when I did I was thinking "I don't expect anyone to see this...". 2 of them got closed with 1.3.1 release. When I saw the 1.3.1 announcement, I was totally surprised. The 1.3.0 released just one day before, was never announced. There was no discussion on the list about the plans, no pre-release for us to test etc. I mean, even Remi's queries "Is libupnp maintained ?" and "automake and autoconf for libupnp ?" back in Oct 13 2005 remained unanswered in the dev list. Obviously, they were answered/discussed privately but this does not help to attract more developers. I think you could have been more clear about "help wanted"; as you just did ;-) So, I'd like to help with the project anyway I can (when time permits). BR, Nektarios Dan Baumberger wrote: > 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 > > |
|
From: <tur...@ea...> - 2006-04-11 20:57:39
|
On Monday 10 April 2006 22:06, R=E9mi wrote: > qx...@gm... wrote: I hope you got my answer through this mailing list ; the copy I sent you=20 directly is rejected by your mail server. =2D-=20 R=E9mi |
|
From: <tur...@ea...> - 2006-04-10 20:12:26
|
qx...@gm... wrote: > So what switch was defined for Sparc Solaris systems for that proje= ct? > =20 this is autoconf, so normally we don't target a specific platform her= e=20 (and anyway, a single define wouldn't make sense alone : which OS= =20 version, compiler, ... ?). Instead we target specific features=20 (absence/presence of header files, symbols, tools, or more complex= =20 cases) through the configure file. This allow easier evolution to oth= er=20 platforms, versions, ... If you want, I can help here, and provide the necessary configure.ac= =20 changes. This will not make your changes more complex (replace #if= =20 SPARC_SOLARIS by #if HAVE_xxx_feature (except in publicly installed= =20 header files)). On the contrary, it will simplify further porting. > Btw: The autoconf/automake tools IMHO are a monstrosity, complicate= d and > mainly unnecessary chump of software. > =20 there are a bit monstrous at first, I agree, but no other tool does a= n=20 equivalent job, with the same level of pre-automated tasks (this is w= hy=20 it is used in a majority of open-sources projects). As soon as you have some non-trivial code that you want to run on= =20 different Unix flavors, compilers and environment, you have to go in= =20 that direction. For example in libupnp now, you shouldn't have to wor= ry=20 anymore about the shared or static library production, or versionning= ,=20 or the pthread flags to use, ... R=E9mi |
|
From: John D. <jd...@re...> - 2006-04-10 19:13:26
|
On Mon, 2006-04-10 at 09:11 +0200, qx...@gm... wrote: > So what switch was defined for Sparc Solaris systems for that project? There are several ways to skin this cat, one solution would be adding this to configure.ac AC_DEFINE_UNQUOTED([HOST_OS], "$host_os", [target operating system]) Then in autoconfig.h you'll get something like this: /* target operating system */ #define HOST_OS "solaris" Then in your C code you can do something like this: #if HOST_OS = "solaris" #endif Note: I'm not sure the exact string that solaris will produce for HOST_OS, you'll just have to run autoreconf;configure and see how HOST_OS gets defined, but "solaris" is a pretty good bet (note on linux it's "linux-gnu") If its a sparc only distinction you'll have to add "host_cpu" too. > > Btw: The autoconf/automake tools IMHO are a monstrosity, complicated and > mainly unnecessary chump of software. I agree that autoconf/automake has a steep learning curve and at times can be frustrating, but its the only viable game in town for open source configuration and the definitive standard. Like it or not, its the right way to do things. IMHO the autotool support that was added by Remi was a huge improvement over the previous non-portable feature poor makefiles (they couldn't even produce a debug static library, which is now trival using automake). -- John Dennis <jd...@re...> Red Hat Inc. |
|
From: <qx...@gm...> - 2006-04-10 07:12:06
|
So what switch was defined for Sparc Solaris systems for that project? Btw: The autoconf/automake tools IMHO are a monstrosity, complicated and mainly unnecessary chump of software. > I also noticed some new "#if SPARC_SOLARIS" in the code. I don't think > this > should be done this way : the libupnp production has been ported to > autoconf/automake, so any specific feature should now be tested in > configure > and the code should rely on autoconfig.h. -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner |
|
From: <tur...@ea...> - 2006-04-09 13:37:59
|
Hello, I just noticed that changes have been commited to the libupnp CVS, but the= =20 ChangeLog file has not been updated. I think it is mandatory, in a=20 multi-developper enviroenement, to update this file for every change, else= =20 there is no simple way to track all that happens. Can the respective commiters update the file for the last changes ? I also noticed some new "#if SPARC_SOLARIS" in the code. I don't think this= =20 should be done this way : the libupnp production has been ported to=20 autoconf/automake, so any specific feature should now be tested in configur= e=20 and the code should rely on autoconfig.h. In the same way, there shouldn't be a "Makefile.sparcsolaris" commited in t= he=20 CVS. Best regards, R=E9mi |
