Kevron, > -----Original Message----- > From: Rees, Kevron [mailto:kevron.m.rees at intel.com] > Sent: Tuesday, April 14, 2015 4:46 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib > > I wasn't aware that glib was being used for all multi-threaded platforms. > For > linux, this is almost a no-brainer, but you still have to throw the license > argument out the window.
It is all good. Keep asking and challenging. If we can close these gaps and I can get a lawyer to tell me that I am safe in the scenarios that I am concerned about, we may be good. > You could use c++11 threads/mutexes instead, however, you'll probably run > into the same problems on many platforms with dubious c++11 support. Right. > Finally, is it a rational goal to work on every platform imaginable? > You'll spend more time/resources/money fixing code for each platform and > may end up inventing yet-another-buggy-os-abstraction-framework > when all is said and done. Does iotivity have a defined number of target > platforms? I ask regularly. I personally only want to support any commercial viable platform (Android, iOS, linux, etc.) and target representative platforms (one bare metal and one RTOS). The bare metal and RTOS address embedded hardware in spaces like fitbits, in-wall switches, light bulbs, etc. If we cannot demonstrate support of these types of devices, I am not sure that anybody would want to take on the refactoring get into these spaces. I leave the porting to and support of your preferred non-supported hardware as an exercise for the vendor. That said, Iotivity or OIC can change my priorities and drop these target devices. However, in that case, I would feel that we are only building for the Internet of Big Things (IOBT). One more note, Glib is about 1.7 MB which not too bad on a fat device like a phone or tablet. So the size does not concern me at this point. In the past, we have had products that included communication frameworks that supported iOS, Android, Windows, etc. The Android ISVes started objecting when the framework (with ARM and x86 support) exceeded 4-6MB because their users would complain about the app download size. So, I am watching our footprint size. Pat > On Tue, Apr 14, 2015 at 1:32 PM, Lankswert, Patrick > <patrick.lankswert at intel.com> wrote: > > Kevron, > > > > IANAL, LPGL v2 on this issue has not been legally challenged for > > embedded environments. The LGPL v2 is a little ambiguous on the binary > > substitution requirements. LGPL v3 was created to close the ambiguity. > > Many like to point to Android and iOS use of webkit, but neglect to > > mention that it is LGPL and BSD licensed. From what I can see, if we > > need to support a platform that does not support dynamic linking, the LGPL > will be a problem. > > > > Are you aware of well-supported glib implementations that is available > > for iOS, Win32, WinRT or RTOSes like Contiki, uCOS, etc. > > > > What is more work, porting glib to the next OS/RTOS or implementing a > > thread and mutex wrapper for each OS? > > > > Pat > > > >> -----Original Message----- > >> From: Rees, Kevron [mailto:kevron.m.rees at intel.com] > >> Sent: Tuesday, April 14, 2015 3:56 PM > >> To: Lankswert, Patrick > >> Cc: iotivity-dev at lists.iotivity.org > >> Subject: Re: [dev] glib > >> > >> Also, I'm not sure "1" is actually a problem. This is not GPL 3 that > >> requires the device to be hackable where you could replace a lgpl > >> library. Literally hundreds of devices ship with LGPL code. > >> > >> On Tue, Apr 14, 2015 at 12:51 PM, Rees, Kevron > >> <kevron.m.rees at intel.com> > >> wrote: > >> > You should be using glib for mainloop functionality as well (avoids > >> > having to use threads at all), but it should be pluggable (able to > >> > be replaced with Qt or other mainloops systems as desired). > >> > > >> > > >> > > >> > On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick > >> > <patrick.lankswert at intel.com> wrote: > >> >> To all, > >> >> > >> >> The introduction of glib has complicated the stack in a number of > >> >> ways from licensing to OS support and beyond. > >> >> > >> >> In the future, do not draw in additional libraries into Iotivity > >> >> without vetting it in this forum. > >> >> > >> >> I plan to remove the glib dependency from iotivity for several > >> >> reasons: > >> >> 1) IANAL, but the license has viral requirements including the > >> >> fact that a dynamically linked LGPL library must be replaceable > >> >> which is a problem for RTOSes and linux-based devices TVs and Access > Points. > >> >> 2) Glib support on iOS (not directly supported), OSX and Windows > >> >> (requires > >> >> MSYS) is problematic > >> >> 3) It is my understanding that we are only using glib for threads > >> >> and > >> mutex. > >> >> This is a lot to pull into iotivity for only two features. > >> >> > >> >> Before I make this official, I would like to understand any reason > >> >> that glib should be kept. Are we using glib for anything other > >> >> than threads and mutexes? > >> >> > >> >> Pat > >> >> > >> >> Patrick Lankswert > >> >> > >> >> Intel Corporation > >> >> Platform Engineering Group (PEG) / Communications and Devices > >> >> Group > >> >> (CDG) Engineering Manager Louisville, KY, USA > >> >> > >> >> > >> >> _______________________________________________ > >> >> iotivity-dev mailing list > >> >> iotivity-dev at lists.iotivity.org > >> >> https://lists.iotivity.org/mailman/listinfo/iotivity-dev > >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150414/3fad66d6/attachment.p7s>
