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: <go...@so...> - 2007-06-29 01:50:06
|
Nektarios K. Papadopoulos wrote: > I didn't look your code, but I know that building a proper combo of > control point and device is not possible with upnp-sdk. > > This is fixed in the successor of this project pupnp: > http://sourceforge.net/projects/pupnp > > > gokeigen wrote: >> I have a problem when i build control point and device into one process. >> source code is listed down.If the function of >> "UpnpSendAdvertisement"is called,the control point can not download >> description document from mini >> http server.But,if "UpnpSendAdvertisement"is not called,everything is >> ok.what is wrong with my program? >> >> /* routine */ >> int upnpDeviceStart() >> { >> int ret = UPNP_E_SUCCESS; >> char* web_dir_path = "./web"; >> >> ret = UpnpSetWebServerRootDir(web_dir_path); >> if(ret != UPNP_E_SUCCESS) >> { >> ERROR_PRINTF("Specifying webserver root directory --> %s >> failure!\n >> \ >> Error Code : %d\n",web_dir_path,ret); >> upnpFinish(); >> return ret; >> } >> >> char* ip = NULL; >> unsigned short port; >> char desc_File_url[256]; >> char* pDesc_File_Name = "tvdevicedesc.xml"; >> >> ip = UpnpGetServerIpAddress(); >> port = UpnpGetServerPort(); >> >> sprintf(desc_File_url,"http://%s:%d/%s",ip,port,pDesc_File_Name); >> DBG_PRINTF("descfileurl --> %s\n",desc_File_url); >> >> ret = UpnpRegisterRootDevice(desc_File_url, >> upnpDeviceCallbackEventHandler, >> &deviceHandle, >> &deviceHandle); >> if(ret != UPNP_E_SUCCESS) >> { >> ERROR_PRINTF("Registering the rootdevice --> %s failure!\n \ >> Error Code : >> %d\n",&desc_File_url[0],ret); >> upnpFinish(); >> return ret; >> } >> #if 1 >> ret = UpnpSendAdvertisement(deviceHandle,Device_Advr_Expire); >> if(ret != UPNP_E_SUCCESS) >> { >> ERROR_PRINTF("Sending advertisements --> %d\n \ >> Error Code : %d\n",ret); >> upnpFinish(); >> return ret; } >> #endif return ret; >> } >> >> /* debug message when "UpnpSendAdvertisement" is called */ >> [DEBUG]upnpctrlInit(). >> [DEBUG]descfileurl --> http://127.0.0.1:49152/tvdevicedesc.xml >> >> cmd> [DEBUG]DISCOVERY_SEARCH_TIMEOUT >> [DEBUG]DISCOVERY_SEARCH_TIMEOUT >> Error: Error obtaining device description from >> http://127.0.0.1:49152/tvdevicedesc.xml [DEBUG]retCode: -207 >> >> /* wget message */ >> [lnkinprk@npc0705 ~]$ wget --no-proxy >> http://127.0.0.1:49152/tvdevicedesc.xml >> --19:19:18-- http://127.0.0.1:49152/tvdevicedesc.xml >> Connecting to 127.0.0.1:49152... connected. >> HTTP request sent, awaiting response... >> /* debug message when "UpnpSendAdvertisement" is not called */ >> [DEBUG]upnpctrlInit(). >> [DEBUG]descfileurl --> http://127.0.0.1:49154/tvdevicedesc.xml >> >> cmd> [DEBUG]Add to Device Summary:UPnP Television Emulator >> [DEBUG]DISCOVERY_SEARCH_TIMEOUT >> >> /* wget message */ >> [lnkinprk@npc0705 ~]$ wget --no-proxy >> http://127.0.0.1:49153/tvdevicedesc.xml >> --19:28:07-- http://127.0.0.1:49153/tvdevicedesc.xml >> Connecting to 127.0.0.1:49153... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 1532 (1.5K) [text/xml] >> Saving to: `tvdevicedesc.xml.4' >> >> 100%[=======================================>] 1,532 --.-K/s in >> 0s >> 19:28:07 (196 MB/s) - `tvdevicedesc.xml.4' saved [1532/1532] >> >> >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Upnp-sdk-dev mailing list >> Upn...@li... >> https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev >> > Thank you for your reply! But it is happend on portable upnp sdk 1.6.0 |
|
From: Nektarios K. P. <npa...@in...> - 2007-06-28 09:07:39
|
I didn't look your code, but I know that building a proper combo of control point and device is not possible with upnp-sdk. This is fixed in the successor of this project pupnp: http://sourceforge.net/projects/pupnp gokeigen wrote: > I have a problem when i build control point and device into one process. > source code is listed down.If the function of "UpnpSendAdvertisement"is > called,the control point can not download description document from mini > http server.But,if "UpnpSendAdvertisement"is not called,everything is > ok.what is wrong with my program? > > /* routine */ > int upnpDeviceStart() > { > int ret = UPNP_E_SUCCESS; > char* web_dir_path = "./web"; > > ret = UpnpSetWebServerRootDir(web_dir_path); > if(ret != UPNP_E_SUCCESS) > { > ERROR_PRINTF("Specifying webserver root directory --> %s failure!\n > \ > Error Code : %d\n",web_dir_path,ret); > upnpFinish(); > return ret; > } > > char* ip = NULL; > unsigned short port; > char desc_File_url[256]; > char* pDesc_File_Name = "tvdevicedesc.xml"; > > ip = UpnpGetServerIpAddress(); > port = UpnpGetServerPort(); > > sprintf(desc_File_url,"http://%s:%d/%s",ip,port,pDesc_File_Name); > DBG_PRINTF("descfileurl --> %s\n",desc_File_url); > > ret = UpnpRegisterRootDevice(desc_File_url, > upnpDeviceCallbackEventHandler, > &deviceHandle, > &deviceHandle); > if(ret != UPNP_E_SUCCESS) > { > ERROR_PRINTF("Registering the rootdevice --> %s failure!\n \ > Error Code : %d\n",&desc_File_url[0],ret); > upnpFinish(); > return ret; > } > #if 1 > ret = UpnpSendAdvertisement(deviceHandle,Device_Advr_Expire); > if(ret != UPNP_E_SUCCESS) > { > ERROR_PRINTF("Sending advertisements --> %d\n \ > Error Code : %d\n",ret); > upnpFinish(); > return ret; > } > #endif > return ret; > } > > /* debug message when "UpnpSendAdvertisement" is called */ > [DEBUG]upnpctrlInit(). > [DEBUG]descfileurl --> http://127.0.0.1:49152/tvdevicedesc.xml > > cmd> [DEBUG]DISCOVERY_SEARCH_TIMEOUT > [DEBUG]DISCOVERY_SEARCH_TIMEOUT > Error: Error obtaining device description from > http://127.0.0.1:49152/tvdevicedesc.xml > [DEBUG]retCode: -207 > > /* wget message */ > [lnkinprk@npc0705 ~]$ wget --no-proxy > http://127.0.0.1:49152/tvdevicedesc.xml > --19:19:18-- http://127.0.0.1:49152/tvdevicedesc.xml > Connecting to 127.0.0.1:49152... connected. > HTTP request sent, awaiting response... > > /* debug message when "UpnpSendAdvertisement" is not called */ > [DEBUG]upnpctrlInit(). > [DEBUG]descfileurl --> http://127.0.0.1:49154/tvdevicedesc.xml > > cmd> [DEBUG]Add to Device Summary:UPnP Television Emulator > [DEBUG]DISCOVERY_SEARCH_TIMEOUT > > /* wget message */ > [lnkinprk@npc0705 ~]$ wget --no-proxy > http://127.0.0.1:49153/tvdevicedesc.xml > --19:28:07-- http://127.0.0.1:49153/tvdevicedesc.xml > Connecting to 127.0.0.1:49153... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1532 (1.5K) [text/xml] > Saving to: `tvdevicedesc.xml.4' > > 100%[=======================================>] 1,532 --.-K/s in > 0s > > 19:28:07 (196 MB/s) - `tvdevicedesc.xml.4' saved [1532/1532] > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Upnp-sdk-dev mailing list > Upn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev > -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Home Automation Group inAccess Networks ______________________________________________________________ |
|
From: gokeigen <go...@so...> - 2007-06-20 10:39:02
|
I have a problem when i build control point and device into one process.
source code is listed down.If the function of "UpnpSendAdvertisement"is
called,the control point can not download description document from mini
http server.But,if "UpnpSendAdvertisement"is not called,everything is
ok.what is wrong with my program?
/* routine */
int upnpDeviceStart()
{
int ret = UPNP_E_SUCCESS;
char* web_dir_path = "./web";
ret = UpnpSetWebServerRootDir(web_dir_path);
if(ret != UPNP_E_SUCCESS)
{
ERROR_PRINTF("Specifying webserver root directory --> %s failure!\n
\
Error Code : %d\n",web_dir_path,ret);
upnpFinish();
return ret;
}
char* ip = NULL;
unsigned short port;
char desc_File_url[256];
char* pDesc_File_Name = "tvdevicedesc.xml";
ip = UpnpGetServerIpAddress();
port = UpnpGetServerPort();
sprintf(desc_File_url,"http://%s:%d/%s",ip,port,pDesc_File_Name);
DBG_PRINTF("descfileurl --> %s\n",desc_File_url);
ret = UpnpRegisterRootDevice(desc_File_url,
upnpDeviceCallbackEventHandler,
&deviceHandle,
&deviceHandle);
if(ret != UPNP_E_SUCCESS)
{
ERROR_PRINTF("Registering the rootdevice --> %s failure!\n \
Error Code : %d\n",&desc_File_url[0],ret);
upnpFinish();
return ret;
}
#if 1
ret = UpnpSendAdvertisement(deviceHandle,Device_Advr_Expire);
if(ret != UPNP_E_SUCCESS)
{
ERROR_PRINTF("Sending advertisements --> %d\n \
Error Code : %d\n",ret);
upnpFinish();
return ret;
}
#endif
return ret;
}
/* debug message when "UpnpSendAdvertisement" is called */
[DEBUG]upnpctrlInit().
[DEBUG]descfileurl --> http://127.0.0.1:49152/tvdevicedesc.xml
cmd> [DEBUG]DISCOVERY_SEARCH_TIMEOUT
[DEBUG]DISCOVERY_SEARCH_TIMEOUT
Error: Error obtaining device description from
http://127.0.0.1:49152/tvdevicedesc.xml
[DEBUG]retCode: -207
/* wget message */
[lnkinprk@npc0705 ~]$ wget --no-proxy
http://127.0.0.1:49152/tvdevicedesc.xml
--19:19:18-- http://127.0.0.1:49152/tvdevicedesc.xml
Connecting to 127.0.0.1:49152... connected.
HTTP request sent, awaiting response...
/* debug message when "UpnpSendAdvertisement" is not called */
[DEBUG]upnpctrlInit().
[DEBUG]descfileurl --> http://127.0.0.1:49154/tvdevicedesc.xml
cmd> [DEBUG]Add to Device Summary:UPnP Television Emulator
[DEBUG]DISCOVERY_SEARCH_TIMEOUT
/* wget message */
[lnkinprk@npc0705 ~]$ wget --no-proxy
http://127.0.0.1:49153/tvdevicedesc.xml
--19:28:07-- http://127.0.0.1:49153/tvdevicedesc.xml
Connecting to 127.0.0.1:49153... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1532 (1.5K) [text/xml]
Saving to: `tvdevicedesc.xml.4'
100%[=======================================>] 1,532 --.-K/s in
0s
19:28:07 (196 MB/s) - `tvdevicedesc.xml.4' saved [1532/1532]
|
|
From: Nektarios K. P. <npa...@in...> - 2006-10-09 14:18:11
|
Just to let you know that Song Weijia has uploaded his path at [1]. He started working on IPv6 support on a subversion branch. AFAICT he is on experimental state also, so perhaps you can get in touch and work together. No need to duplicate effort :-) You can discuss your ideas on punp-devel list. [1]https://sourceforge.net/tracker/?func=detail&atid=841028&aid=1570733&group_id=166957 Nektarios K. Papadopoulos wrote: > We are in the process to move forum and bug tracker from > www.virtualworlds.de to sourceforge so the link I provided are now invalid. > > Check out http://sourceforge.net/projects/pupnp Patches section, where > Song Weijia, the author of the patch, will soon upload it. > > Looking forward to seeing you in pupnp. Migration from older SDK version > to punp should not be a problem. > > Nilesh Daine wrote: >> Thanks Nektarios ! >> >> Would definately like to join your effort. >> I have been working on a bit older version of upnp-sdk. But that >> shouldn't matter much for IPv6 migration. >> Would you mind providing me that initial/experimental patch ? >> Let me finish of my experiment with older upnp-sdk version and then >> would try to take that onto pupnp which I never tried till now. >> I will join through SF immediately. >> >> -- >> Nilesh >> >> On 9/28/06, *Nektarios K. Papadopoulos* <npa...@in... >> <mailto:npa...@in...>> wrote: >> >> There is an experimental patch[1] against pupnp-1.4.1 that adds initial >> IPv6 support. >> >> pupnp is a relatively recent fork of the upnpsdk that tries to move >> forward. >> >> You are welcome to join our efforts [2] :-) >> >> >> [1]http://libupnp.org/bt/view.php?id=11 >> [2]http://www.virtualworlds.de/forum/index.php#6 >> >> Nilesh Daine wrote: >> > Hi All, >> > >> > Has anybody tried adding support for IPv6 in libupnp for IGD >> profile ? >> > Any thoughts would be helpful in that regard. >> > >> > Thanks, >> > Nilesh >> > >> > >> > > > -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: Nektarios K. P. <npa...@in...> - 2006-10-03 15:56:22
|
We are in the process to move forum and bug tracker from www.virtualworlds.de to sourceforge so the link I provided are now invalid. Check out http://sourceforge.net/projects/pupnp Patches section, where Song Weijia, the author of the patch, will soon upload it. Looking forward to seeing you in pupnp. Migration from older SDK version to punp should not be a problem. Nilesh Daine wrote: > Thanks Nektarios ! > > Would definately like to join your effort. > I have been working on a bit older version of upnp-sdk. But that > shouldn't matter much for IPv6 migration. > Would you mind providing me that initial/experimental patch ? > Let me finish of my experiment with older upnp-sdk version and then > would try to take that onto pupnp which I never tried till now. > I will join through SF immediately. > > -- > Nilesh > > On 9/28/06, *Nektarios K. Papadopoulos* <npa...@in... > <mailto:npa...@in...>> wrote: > > There is an experimental patch[1] against pupnp-1.4.1 that adds initial > IPv6 support. > > pupnp is a relatively recent fork of the upnpsdk that tries to move > forward. > > You are welcome to join our efforts [2] :-) > > > [1]http://libupnp.org/bt/view.php?id=11 > [2]http://www.virtualworlds.de/forum/index.php#6 > > Nilesh Daine wrote: > > Hi All, > > > > Has anybody tried adding support for IPv6 in libupnp for IGD > profile ? > > Any thoughts would be helpful in that regard. > > > > Thanks, > > Nilesh > > > > > > -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: Nektarios K. P. <npa...@in...> - 2006-09-28 14:23:14
|
There is an experimental patch[1] against pupnp-1.4.1 that adds initial IPv6 support. pupnp is a relatively recent fork of the upnpsdk that tries to move forward. You are welcome to join our efforts [2] :-) [1]http://libupnp.org/bt/view.php?id=11 [2]http://www.virtualworlds.de/forum/index.php#6 Nilesh Daine wrote: > Hi All, > > Has anybody tried adding support for IPv6 in libupnp for IGD profile ? > Any thoughts would be helpful in that regard. > > Thanks, > Nilesh > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Upnp-sdk-dev mailing list > Upn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: Nilesh D. <nd...@gm...> - 2006-09-25 13:31:39
|
Hi All, Has anybody tried adding support for IPv6 in libupnp for IGD profile ? Any thoughts would be helpful in that regard. Thanks, Nilesh |
|
From: <qx...@gm...> - 2006-06-06 12:57:45
|
Thats my last posting to the list of the Project UPnP to inform all the people that still may stay here: The Project PUPnP (that is the successor of the dead project LibUPnP) has released its first version that is independet from this project. Version 1.4.0 of our libupnp is fully compatible to the one of the project UPnP and contains all the patches, fixes and enhancements that never found their way into the old libupnp. The homepage of the new Projcet PUPnP (that contains several interesting information and links to the projects webboard) can be found at http://pupnp.sf.net , the changelog of version 1.4.0 is available at http://virtualworlds.de/upnp/ChangeLog Once again: the fully compatible libupnp 1.4.0 is available only from project PUPnP (Portable SDK for UPnP Devices), project UPnP (Linux SDK for UPnP Devices) has stalled with version 1.3.1 Michael -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: Michael P. <qx...@gm...> - 2006-05-26 09:00:54
|
Hi Ravi, under http://www.virtualworlds.de/forum/index.php/topic,190.0.html it is discussed what to add and what to change at the libupnp, please have a look there. Any help and contributions are greatly welcome! Michael > -------- Original-Nachricht -------- > Datum: Fri, 26 May 2006 14:15:35 +0530 > Von: Ravi Nanjundappa <rav...@ap...> > An: qx...@gm... > Betreff: Re: [UPnP-SDK-discuss] Invitation for developers / libupnp 1.4.0 > > Hi All, > I am a new entry for the group. > I am interested in the current activity that you people are planning for . > > Can I also contribute for the group work ?? > > N Ravi > > qx...@gm... wrote: > > >After the successful fork from project UPnP the new project "Portable > >UPnP" (http://www.sf.net/projects/pupnp , webboard at > >http://www.virtualworlds.de/forum/index.php#6 ) made a serious progress, > >so that we're now in a state to go forward to version 1.4.0 (please > >refer to http://www.virtualworlds.de/forum/index.php/topic,196.0.html ). > > > >Because of that I want to invite all developers to our project: > > > >- the ones that have contributed code or patches to test if it works as > >expected > >- the ones from the old project UPnP (I remember at least one that was > >active there) to take part at the new project > >- and of course the ones that found other bugs or problems and want to > >report them or contribute fixes > > > >Michael > > > >> > -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer |
|
From: <qx...@gm...> - 2006-05-26 07:19:31
|
After the successful fork from project UPnP the new project "Portable UPnP" (http://www.sf.net/projects/pupnp , webboard at http://www.virtualworlds.de/forum/index.php#6 ) made a serious progress, so that we're now in a state to go forward to version 1.4.0 (please refer to http://www.virtualworlds.de/forum/index.php/topic,196.0.html ). Because of that I want to invite all developers to our project: - the ones that have contributed code or patches to test if it works as expected - the ones from the old project UPnP (I remember at least one that was active there) to take part at the new project - and of course the ones that found other bugs or problems and want to report them or contribute fixes Michael -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer |
|
From: <un...@th...> - 2006-05-24 11:02:33
|
Hi, is it possible to build a program using libupnp which implements a contro= l point AND a mediarenderer? It seems to be a problem, that the upnp-sdk could only be initialized onc= e per process, because then the root and the client device are bound to t= he same port. The root device wants to start it's websever and the client wants to list= en on the same port --> doesn't work Is there a way arount this? Or do I have to build two programs? |
|
From: <qx...@gm...> - 2006-05-17 14:46:32
|
> One thing I was never comfortable with was how the SDK implemented it's > own version of what is now otherwise common interfaces, for example XML > parsing and generation, but there are other examples too (e.g. > threading). There would be less bloat if one would leverage off of the > work of other projects by linking against existing libraries rather than > trying to do it all Nice idea. After this one here is the mailing list of the old project, I created an appropriate thread for the portable libupnp at http://www.virtualworlds.de/forum/index.php/topic,190.0.html Michael -- Mobile Internet - E-Mail und Internet immer und überall! GMX zum Mitnehmen: http://www.gmx.net/de/go/pocketweb |
|
From: John D. <jd...@re...> - 2006-05-17 14:07:55
|
On Wed, 2006-05-17 at 12:21 +0200, qx...@gm... wrote: > One main focus beside of the further development of it are porting the > library to other operating systems so that it is able to become a standard > for UPnP applications. One thing I was never comfortable with was how the SDK implemented it's own version of what is now otherwise common interfaces, for example XML parsing and generation, but there are other examples too (e.g. threading). There would be less bloat if one would leverage off of the work of other projects by linking against existing libraries rather than trying to do it all. For example let the XML folks worry about producing the smallest fastest most robust XML code and let the UPNP folks become familar with just one API that will serve them on other projects as well. I think I understand why the original developers choose to implement everything themselves, at the time of the original development standard libraries did not exist for many of these technologies, but they do now. Perhaps one thing which could be done is to trim down and simplify the project by utilizing other libraries. I can think of one reason to keep the existing "do it all" approach, it may provide the smallest footprint if embedded devices are considered a primary target, but this would need a bit of investigation. The other thing I might suggest, and perhaps I could help with, is that I found the example code to be verbose and awkward. For my project I started with the example code but it wasn't long before I had rewritten much of it. This is of course all a matter of personal style and taste. But for me I found it difficult to get at the essence of how one needed to code using the library because I thought the example code obscured things. I wonder if others had the same reaction. -- John Dennis <jd...@re...> Red Hat Inc. |
|
From: <qx...@gm...> - 2006-05-17 12:02:04
|
First there are several probably useful patches available for the old project that never have been included. They should be added to the sources - as far as they work with the current version, I afraid some are much too old to use them now. Support for IPv6 would be nice too in my opinion. Btw: The libupnp-directory is now available in CVS-tree of the new project. > --- Ursprüngliche Nachricht --- > Von: Kiffin Gish <Kif...@pa...> > An: "'qx...@gm...'" <qx...@gm...>, sf...@en..., > upn...@li..., upn...@li... > Betreff: RE: [upnp-sdk-dev] Fork of project UPnP > Datum: Wed, 17 May 2006 11:48:44 +0100 > > Is there still enough interest in this? If so, then what are the key areas > that we should be concentrating on, besides just porting to other > operating > systems? > > -----Original Message----- > From: upn...@li... > [mailto:upn...@li...] On Behalf Of qx...@gm... > Sent: 17 May 2006 11:21 > To: sf...@en...; upn...@li...; > upn...@li... > Subject: [upnp-sdk-dev] Fork of project UPnP > > Hi, > > there have been discussions within this list about the stalled development > within this project several times. In most cases developers or potential > developers and people that are related to projects using libupnp started > these discussions. > > Here within the list it has been agreed that the maintainership could > change > easily to somebody who is able to start trough with this project. After > all > requests for a project takeover have been denied I decided to create a > fork > out of the current project. > > So now the new project is now available at Sourceforge at > http://sourceforge.net/projects/pupnp it has an own homepage (to avoid the > slow sf.net-servers) at http://www.virtualworlds.de/upnp/ , CVS will be > located at sf.net but isn't fully available yet. > > One main focus beside of the further development of it are porting the > library to other operating systems so that it is able to become a standard > for UPnP applications. > > Developers who are interested in helping with this project are greatly > welcome, we'll of course try to avoid the problems that occured with the > old > project UPnP. > > Kind regards > > Michael > > -- > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail > > > ------------------------------------------------------- > 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 > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Upnp-sdk-dev mailing list > Upn...@li... > https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev > > > > -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: Kiffin G. <Kif...@pa...> - 2006-05-17 10:48:57
|
Is there still enough interest in this? If so, then what are the key areas that we should be concentrating on, besides just porting to other operating systems? -----Original Message----- From: upn...@li... [mailto:upn...@li...] On Behalf Of qx...@gm... Sent: 17 May 2006 11:21 To: sf...@en...; upn...@li...; upn...@li... Subject: [upnp-sdk-dev] Fork of project UPnP Hi, there have been discussions within this list about the stalled development within this project several times. In most cases developers or potential developers and people that are related to projects using libupnp started these discussions. Here within the list it has been agreed that the maintainership could change easily to somebody who is able to start trough with this project. After all requests for a project takeover have been denied I decided to create a fork out of the current project. So now the new project is now available at Sourceforge at http://sourceforge.net/projects/pupnp it has an own homepage (to avoid the slow sf.net-servers) at http://www.virtualworlds.de/upnp/ , CVS will be located at sf.net but isn't fully available yet. One main focus beside of the further development of it are porting the library to other operating systems so that it is able to become a standard for UPnP applications. Developers who are interested in helping with this project are greatly welcome, we'll of course try to avoid the problems that occured with the old project UPnP. Kind regards Michael -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Upnp-sdk-dev mailing list Upn...@li... https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev |
|
From: <qx...@gm...> - 2006-05-17 10:21:48
|
Hi, there have been discussions within this list about the stalled development within this project several times. In most cases developers or potential developers and people that are related to projects using libupnp started these discussions. Here within the list it has been agreed that the maintainership could change easily to somebody who is able to start trough with this project. After all requests for a project takeover have been denied I decided to create a fork out of the current project. So now the new project is now available at Sourceforge at http://sourceforge.net/projects/pupnp it has an own homepage (to avoid the slow sf.net-servers) at http://www.virtualworlds.de/upnp/ , CVS will be located at sf.net but isn't fully available yet. One main focus beside of the further development of it are porting the library to other operating systems so that it is able to become a standard for UPnP applications. Developers who are interested in helping with this project are greatly welcome, we'll of course try to avoid the problems that occured with the old project UPnP. Kind regards Michael -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: Dan B. <dba...@us...> - 2006-05-01 05:48:53
|
As you have already surmised, ithreads.h was used to port the SDK to a couple of non-POSIX operating systems, which, for licensing reasons, = could not be included in the open source release. As far as this project is concerned (separate from what Intel was doing), it no longer serves a = useful purpose and should probably be phased out. The API changes, however, = should not break compatibility, at least as far as libupnp1 is concerned. = Anything that would make applications not compile and/or run against the SDK = should be postponed until a libupnp2 release. - Dan - -----Original Message----- From: upn...@li... [mailto:upn...@li...] On Behalf Of = qx...@gm... Sent: Saturday, April 29, 2006 11:01 PM To: R=E9mi; upn...@li... Cc: Hartwig Deneke Subject: Re: [upnp-sdk-dev] Patches: Remove ithread.h header and change users over to pthreads >> > a user-visible API change that is not good for compatibility. >> >> The problem of a user-visible API change can be aleviatedby carrying = >> around >> the ithread.h file for a while, possibly adding a big warning that it = is >> going to be removed in the future. > > I don't know. > What do other people think ? > I think we should have a decision from the maintainer. ------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Upnp-sdk-dev mailing list Upn...@li... https://lists.sourceforge.net/lists/listinfo/upnp-sdk-dev |
|
From: <tur...@ea...> - 2006-04-30 16:26:57
|
On Thursday 27 April 2006 18:19, Hartwig Deneke wrote: > I have re-uploaded the changes required for getting > rid of ithreads. > This time, I have split this change up into 3 patches this time. btw, you don't need to create a new tracker item each time : one is=20 sufficient, you can attach multiple files if you wish anyway. R=E9mi |
|
From: <qx...@gm...> - 2006-04-30 13:33:14
|
>> > a user-visible API change that is not good for compatibility. >> >> The problem of a user-visible API change can be aleviatedby carrying >> around >> the ithread.h file for a while, possibly adding a big warning that it is >> going to be removed in the future. > > I don't know. > What do other people think ? > I think we should have a decision from the maintainer. |
|
From: <tur...@ea...> - 2006-04-27 20:09:04
|
On Thursday 27 April 2006 18:19, Hartwig Deneke wrote: > > Well, I believe getting rid of code obfuscation is always worth it. Also, > code does bit-rot if it is unmaintained. > Examples of this are already present, as ithread.h currently contains > broken defines (ithread_mutexattr_setkind_np vs. pthread_mutexattr_settype > available on my SUSE Linux 9.3), and does miss functionality available in > my current pthreads package (function pthread_testcancel, macro > PTHREAD_MUTEX_INITIALIZER). I must admit that the ithread is a bit broken. It is incomplete (missing above initializers) which cause using programmes to be more complex than necessary. Also, it exports some non-portable definitions (*_np) which are not available everywhere. So I had trouble when porting the library to FreeBSD : some of the _np definitions are not available exactly in the same way, but are used in the "sample" programs. So should I make a compatible implementation of these definitions on FreeBSD ? It would have been better not to export them in the first place ... > > > a user-visible API change that is not good for compatibility. > > The problem of a user-visible API change can be aleviatedby carrying around > the ithread.h file for a while, possibly adding a big warning that it is > going to be removed in the future. > I don't know. What do other people think ? |
|
From: Hartwig D. <har...@gm...> - 2006-04-27 16:19:58
|
Hi, as the patches somehow disappeared, probably because anonymous upload of patches is not allowed, I have re-uploaded the changes required for getting rid of ithreads. This time, I have split this change up into 3 patches this time. The first = 2 patches change users of the ithread header from the threadutils and the upn= p subdirectory to directly use pthreads, and the last one actually removes this header. Thus, the maintainers have the choice to actually keep around this header file, so external applications using it can continue so for a while, in order not to suddenly break the API (no idea whether the API of libupnp is considered stable already). Any opinions apart from Mike on this subject? Also, a few replies to Mike's statements 2006/4/26, qx...@gm... <qx...@gm...>: > The point is, that there must be a reson for the Intel developers to do i= t > > in that way. What else than the preparation for porting it to other > systems should it be? This is wild guessing, but maybe Intel did have pthreads implementations fo= r other platforms such as windows or vxworks, but decided to not release them= ? Still, I do think they should have made it a separate libpthread then. On the other hand: what do we win with that change? I think nothing, the > code will not become smaller because these defines are replaced by the > preprocessor completely. Well, I believe getting rid of code obfuscation is always worth it. Also, code does bit-rot if it is unmaintained. Examples of this are already present, as ithread.h currently contains broke= n defines (ithread_mutexattr_setkind_np vs. pthread_mutexattr_settype available on my SUSE Linux 9.3), and does miss functionality available in m= y current pthreads package (function pthread_testcancel, macro PTHREAD_MUTEX_INITIALIZER). Beside of that you pointed to an other big problem with that patch: it is > a user-visible API change that is not good for compatibility. The problem of a user-visible API change can be aleviatedby carrying around the ithread.h file for a while, possibly adding a big warning that it is going to be removed in the future. Hartwig |
|
From: John D. <jd...@re...> - 2006-04-26 15:56:55
|
On Wed, 2006-04-26 at 09:40 +0200, qx...@gm... wrote: > Hi, > > I played around a little bit with automake on Solaris and found a big > issue: the library created with autoconf/automake has a size of more than > 1,3 MByte, when I compile it using the same levels of optimization using a > plain Makefile it goes down to about 140 KBytes. > > Currently I don't know what the reason is but I'd suggest that I provide a > specific Makefile for Solaris. Beside the fact that it solves that > sizing-problem using this it is fairly easy to modify it for the usage > with the Sun-compiler that can't be used with autoconf/automake (AFAIK). I > think at least for a Windows-port non-automake-compatible makefiles are > necessary so why don't starting with it here? Hi Michael: Some questions: * There are many makefiles spread out through the directory tree, are you planning on overriding just one or are you providing replacements for every makefile? * The autotools are used extensively on every unix like platform, Solaris included. Libtool, pkgconfig etc. were developed expressly to address the issues of multi-platform building so that platform specific build issues are hidden from users. Solaris is a major platform with with a lot of open source code built for it. I don't know what the specific problem is you're encountering but given the pervasive presence of autotool built components on solaris it seem much more likely there is a small local problem with the autotool usage by libupnp which needs to be fixed rather than the autotool model is broken. I'm concerned if we introduce platform specific makefiles in scattered directories we'll be regressing significantly and introduce a lot of confusion over how tho build which can be avoided. * With respect to windows, it really depends on what environment you're building for. autotools works just fine in a cygnus environment and probably MKS as well. If you want to work in Microsoft's environment then why not use the Microsoft native UPnP libraries? That's what I did when I developed UPnP support which was both linux and windows. Given autotools works in a unix like enviroment in Windows and one has the choice to use native UPnP support on windows I'm not sure that's an argument to throw out autotools in the SDK. Also for what its worth the project is called "UPnP SDK for Linux". While it would be nice for it to build on windows (which it will in a cygnus environment), I'm not sure the porting effort for native windows is worth it given the existing native UPnP support. I appreciate with heart felt sympathy any frustration you're having with the autotool stuff, it can be frustrating, I know all too well. But after getting over a few humps you'll see it's benefits are tremendous. Let's try and find a fix to your problem. Did you compare the arguments passed to the compiler and linker with your makefile and the makefile generated by automake? Can you identify an a build option responsible for the large library size? By any chance is debugging on? -- John Dennis <jd...@re...> Red Hat Inc. |
|
From: <qx...@gm...> - 2006-04-26 15:12:52
|
Hi, I played around a little bit with automake on Solaris and found a big issue: the library created with autoconf/automake has a size of more than 1,3 MByte, when I compile it using the same levels of optimization using a plain Makefile it goes down to about 140 KBytes. Currently I don't know what the reason is but I'd suggest that I provide a specific Makefile for Solaris. Beside the fact that it solves that sizing-problem using this it is fairly easy to modify it for the usage with the Sun-compiler that can't be used with autoconf/automake (AFAIK). I think at least for a Windows-port non-automake-compatible makefiles are necessary so why don't starting with it here? Michael On Mon, 10 Apr 2006 21:13:14 +0200, John Dennis <jd...@re...> wrote: > 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). |
|
From: <qx...@gm...> - 2006-04-26 15:05:36
|
OK, I added some comments to the log. On Mon, 24 Apr 2006 22:19:38 +0200, Rémi <rem...@m4...> wrote: > > qx...@gm... wrote: >> Where can I find that changelog? >> >> > it is the ChangeLog file at the top of the "libupnp" source tree. > > Rémi > > |
|
From: <qx...@gm...> - 2006-04-26 15:05:11
|
The point is, that there must be a reson for the Intel developers to do it in that way. What else than the preparation for porting it to other systems should it be? On the other hand: what do we win with that change? I think nothing, the code will not become smaller because these defines are replaced by the preprocessor completely. What do we lose? In my opinion a (probably small) piece of compatibility. Beside of that you pointed to an other big problem with that patch: it is a user-visible API change that is not good for compatibility. Mike On Wed, 26 Apr 2006 16:45:05 +0200, Hartwig Deneke <har...@gm...> wrote: > 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 > using > 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 |
