Hi Todd, On Thu, 2008-10-02 at 01:29 -0700, Brandt, Todd E wrote: > One other quick note. The DeviceBuilder software may not be very well > known to the people on this list as it was developed outside of SSG. > Lilli Szfranski and Jimmy Huang worked on it prior to their joining > OTC and Lilli has been suggesting for some time that it could be used > on moblin. She introduced me to Bryan Roe who helped develop > DeviceBuilder and is the current maintainer of it (though not actively > anymore as it has been officially end-of-lifed). I've Cced him in this > thread as he is the resident expert on its capabilites.
I can't speak to functionality or code quality of DeviceBuilder - I'll leave that to others. However I am concerned that your suggesting we use software is potentially unacceptable / unworkable for the wider OSS community. Please could you explain to me how an outside developer would work on DeviceBuilder / ilib, for example if they find a bug or missing feature that needs implementing? It sounds to me like they'd have to have a copy of windows and a closed source SDK (DeviceBuilder) - perhaps I'm misunderstanding? Also could you point us to the ilib svn / git repo, or to its history of releases, bugzilla etc, and any other open source communities that are using ilib? > Ross, can you tell us who from OTC-UK is currently working on GUPnp? > How long has it been around? What products has it been used in? AFAIK GUPnP is being used in the next generation of Nokia tablets and is currently a candidate for inclusion in the next release of GNOME Mobile. Paul > -----Original Message----- > From: Brandt, Todd E > Sent: Thursday, October 02, 2008 1:00 AM > To: Ross Burton; Nagarajan, Guru; Szafranski, Lilli; Huang, Jimmy; Roe, Bryan > Y; Moblin Devel > Cc: Matthew Allum; Jussi Kukkonen > Subject: DeviceBuilder/Ilib vs GUPnp > > 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 -- 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
