Actually the libupnp software that you're describing is quite old. In point of fact, Intel's former Home Products Group found it inadequate for some of the same reasons you've described. As a solution they created an SDK for upnp called DeviceBuilder which is used to create a upnp stack for any platform or operating system. The output of this tool, ilib, would be the equivalent of GUPnp but with the following benefits:
1) Ilib has been tested extensively. It has been around for several years and has been productized on multiple hardware and OS platforms. Coincidentally, the examples of testing you mentioned, the playstation and xbox, have actually already been verified. 2) Ilib represents the most up to date software stack for upnp. In fact DeviceBuilder was actually used in the development of the DLNA specification. In theory we could even use DeviceBuilder to create examples for testing GUPnp (which would be redundant of course). 3) Ilib is already DLNA certified. Unfortunately, the DeviceBuilder SDK itself was never made open source, but the software it produces is. Therefore I would like to second what Lilli Szfranski has been suggesting: that we use DeviceBuilder to create a upnp stack for moblin. To be fair, we should investigate what benefits GUPnp has above ilib and come up with an integration plan. Since DeviceBuilder currently has no owner, we could take it over and maintain it from a linux-only, moblin perspective. We wouldn't necessarily have to distribute the DeviceBuilder SDK as part of the moblin development environment. We could just maintain it internally and use it to generate variants of the ilib stack for each of our MID platforms: netbook, etc. There are only two issues that I can see that we would need to iron out if we are to use DeviceBuilder and ilib: 1) The DeviceBuilder SDK is windows software. It produces code for any platform, but the tool is run only on windows. This is really just an internal issue wrt our development environment. 2) The DeviceBuilder's output, ilib, is licensed under the BSD license. We would need to investigate whether moblin ilib could be licensed as GPL; or if BSD and GPL could coesxist. Comments? -----Original Message----- From: Ross Burton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 3:03 AM To: Brandt, Todd E Cc: Matthew Allum; Jussi Kukkonen Subject: Re: GUPnp Hi Todd, (ccing Matthew and Jussi, who is also looking at DLNA compliance in gupnp) On Tue, 2008-09-30 at 15:30 -0700, Brandt, Todd E wrote: > Hi Ross, I've been told that they're switching me over to work on > GUPnp. Unfortunately that's all they've told me. I've looked at the > GUPnp site and it looks to be a linux specific version of what Intel > has for cross platform (with a windows only GUI): > http://www3.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/overview/index.htm > > Can you give me a synopsis of what work needs to be done on GUPnp? GUPnP is a cleanroom SSDP/UPnP implementation, based on GObject and as such can offer a lot more to the programmer such as auto-marshalling of data and autogenerated bindings. The core premise -- and why we didn't use the existing (although seemingly unmaintained?) Intel libupnp -- is that libgupnp is trivial to integrate into GLib applications (such as GTK+ or Clutter). It doesn't block or use threads[1], integrates into the main loop, the API is based around GObjects with signals and properies, and so on. Earlier in the year I blogged a few times about what is going on in gupnp. Probably the simpliest gupnp application: http://burtonini.com/blog/computers/gupnp-basics-2008-05-12-12-50 Magic bindings generation: http://burtonini.com/blog/computers/gupnp-binding-2008-05-23-16-40 One of the most important areas that needs work in GUPnP is compatibility with other devices. There are reference media servers, renderers and control points in the GUPnP tree which *should* let you communicate with various devices such as the XBox 360 and Playstation 3, but these haven't been really tested. There are several potential failure points: 1) libgupnp is either incorrectly implementing the specification, or implementing the specification too strictly for other devices. Problems like this are getting rarer, but some may exist still with devices we've not tested before. Generally a copy of the specification and an ethernet traffic sniffer will be sufficient to debug these 2) The media applications need work. The media server in particular only implements a small subset of the specification so its likely that (for example) the playstation makes searches we currently don't support, or the xbox expects there to be another service running too (actually, that is true). So, taking a popular device such as a Playstation 3 or XBox 360 and testing/fixing the media server so that it can provide content to the device would be great. Alternatively test that the gupnp media renderer can play media from the device. Existing UPnP media servers (such as fuppes) can provide hints as to what workarounds are required here, and it doubles as a great way of attempting to expense a Playstation. ;) If you have any other questions then feel free to email me. Cheers, Ross [1] well, libsoup currently will use threads to do async DNS lookups, but libgupnp doesn't do DNS lookups -- Intel Open Source Technology Centre http://oss.intel.com/ _______________________________________________ Moblin dev Mailing List [email protected] To manage or unsubscribe from this mailing list visit: https://lists.moblin.org/mailman/listinfo/dev or your user account on http://moblin.org once logged in. For more information on the Moblin Developer Mailing lists visit: http://moblin.org/community/mailing-lists
