I watched the discussion about the poor state of the original libupnp for a long time and I also tried to change something there.
It ended up with the information that the maintainer is willing to hand over the project to somebody else who has eough time to manage that project but all project takeover requests have been denied.
So I decided to create a fork out of the project and named it PUPnP for "Portable UPnP". That library will be fully compatible with the libupnp (and for a first step use the same name) but there will be a further development.
So I invite the developers of the project MediaTomb to take part at this development and to provide their changes, more information are available at the home page at http://pupnp.sf.net
I hope it is no longer necessary for you to hold an own branch of the libupnp within your source tree, the development of the libupnp will go on.
I know :) I have been following the discussions on the UPnP SDK mailinglist.
Well, it would be for sure good if we work together, however at this point I would still like to stick to the "integrated" library. If your project develops in the right direction we can switch back (I still keep the separation in the code).
I also read about your idea to replace the XML parser, etc. On one side it is a good idea to use other libraries, on the other it will introduce more dependencies - my concern are embedded devices. Actually I would like to write a completely new SDK but unfortunately I do not have time for that at this point.
Please note, that the SDK in our sources will be released under the LGPL license. Are you going to keep the BSD license? I am just thinking that this could be somewhat a problem if our changes should go back to the original library.
It would be good if we align on the features/fixes that are required in order to avoid duplicate work.
Btw, I will be offline for 2 weeks, so I guess it would make sense to talk in more detail when I come back.
Nektarios K. Papadopoulos
Just my 2 cents regarding XML parser, etc. based on my own experience on some (not so small) embedded devices. It is often the case that a threading and xml library is required by other applications too. So if these libraries are common then you actually gain space-wise.
Additionaly, libxml for example can be configured with the specific features one requires in order to avoid wasting space on unneeded features.
I think it is not possible that easy to change to a different license. The BSD-license was specified by the original developers from Intel. As far as I'm familar with it, to change the license I would have to ask all the Intel-developers and all contributors that came afterwards if they agree to change the license. Thats something that is nearly impossible.
The idea to replace the XML-functionality by a standard library came exactly from the fact that there several resources could be saved but at the moment nothing is decided definitely.
Btw: your DSM 320 patch has been integrated: http://www.virtualworlds.de/forum/index.php/topic,191.0.html
Changing the license type from BSD is pretty easy as it only has fairly simple attribution requirements.
I'm not sure I see the point in changing the license to a somewhat more restrictive one.
That depends on the license - you can not go from GPL to BSD, but you can go from BSD to L/GPL. (BSD basically says that you can do whatever you want with the code as long as you keep the copyright notice of the original author). I still need to investigate that topic a little further, but I am confident that this can be done.
The reasons - well, if I am sharing my work with others, I want others to share their work with me. I simply would not like to see my code in some closed source commercial projects.
Regarding the DSM-320 patch - actually I am going to imrove it (I would like to have DSM-320 support configurable - enabled/disabled). Not that the redsonic headers does any harm to other renderers, but it still would be cleaner to enable it only if required.
Regarding the XML library - well, Nektarios was saying that it is also possible to trim down the XML parser library; so it would not be an issue for embedded devices. If that is the case we could surely think about replacing the libupnp XML parser. Right now I do not really see a high priority for this since the ixml stuff does what it's supposed to - the main issue is that it's just very ugly :)
In MediaTomb we anyway wrote an own primitive parser and a DOM oriented but a very easy to use XML class, based on the zmm templates which were written by Gena.
Currently there is no decision made about removing the XML-functionality. The argument that on an embedded device only libupnp is required what would save some space there is a very strong one. So wouldn't it be an idea to work with some switches within libupnp so that on such an embedded device only the important parts are available?
Btw: are the sources of your modified libupnp available as .tar.gz somewhere? I could not find it on your project page and it seems you're not using the SF.net-CVS...
we are currently in Russia, I will come back to you when we return (after 3. of June)
Hi, we are back from our vacation :)
Well, basically I prefer to have everything configurable. Allthough I am not sure how to handle this when using a library. When you have an application you can always compile it "your way" - nothing else depends on it. It may be a different situation when you have a library - there some decision regarding the "defaults" has to be made.
So - probably you would distribute a precompiled package with default values, but still allow switches for people who want to compile/use the library on embedded devices or with different configurations.
We decided to integrate the libupnp sources in our tree in order to avoid conflicts with the system-wide library and also in order to have the freedom to introduce chagnes and patches as needed.
We indeed are not using the SF-CVS services, we plan to switch to SF-SVN with the 0.9 release but currently nothing is available. I can make you a tar.gz of the libupnp subdirectory if you want to look at it but it is not really in a distributable state right now. For instance, large file support is not yet complete (range requests are broken).
I'll have to take a look at the changes that you have made to the forked project and see if there is anything that would be interesting for us.
Anyway, we still keep the code separation, so maybe we can switch back to your version of the library once everything gets sorted out and gets somewhat aligned :)