On Tue, 2015-04-14 at 21:27 +0000, Lankswert, Patrick wrote: > 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 seems like a good idea! We (Intel) even own an RTOS mfg, perhaps we could just do that one? > > > > > > > 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. :) Reminds me, I meant to offer to write a forward in the next edition :) > > > > 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 >
