Erich, Because I could not resist...
> -----Original Message----- > From: Keane, Erich > Sent: Tuesday, April 14, 2015 5:06 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org; Rees, Kevron M > Subject: Re: [dev] glib > > On Tue, 2015-04-14 at 21:01 +0000, Lankswert, Patrick wrote: > > 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. > > The big point I have is that we should be simplifying the porting of > Iotivity to > new platforms, the vendor can do it, but we should do what we can to make > it easier. In the glib case, it really is a horrid effort to just get it > running > correctly on a new platform. I believe that if we had a minimal > mutex/threading OSAL to replace the current glib usages with a simply > defined interface, then the vendors could easily just create a simple, > compatible implementation for their platform. This is why I want a representative support platform. If we are supporting an RTOS, chances are it will be easier to port to another RTOS. If we run on a very constrained bare metal device (Arduino or other), it should not be difficult to port to another bare metal device. > > > > 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. > > 2MB is extremely expensive for mutexes and threads. It seems like it is > quite > expensive. I'd be extremely surprised if we couldn't do much better on our > own. Oh, you read my book. :) > > 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 > > > >> >> > > _______________________________________________ > > 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/488335d7/attachment.p7s>
