On Aug 18, 2017 4:29 PM, "Gregg Reynolds" <[email protected]> wrote:
On Aug 18, 2017 3:55 PM, "Mats Wichmann" <[email protected]> wrote: On 08/18/2017 02:40 PM, Thiago Macieira wrote: > On Friday, 18 August 2017 13:22:18 PDT Gregg Reynolds wrote: >> iotivity, the project, or iotivity, the ocf implementation? > > I meant the code that the IoTivity Project releases as "IoTivity". > > That happens to be OCF's reference implementation. > >> my 2 cents: the project is an appropriate home for vendor-contributed >> "add-ons", but the iotivity core/kernel implementation is not. > > Ideally, but maybe it's not feasible for all extensions. And as IoTivity > Project, we want to cope with vendor extensions that may exist out there > anyway, so we may want to accept them in our core files. > it sounds like it's a contrary opinion, but I'd rather have all the code go in to master branch, as long as we provide a way to do a production-targeted build which gives the developer precise control over which non-mandatory features are included/excluded (I would drive that off configuration file with each switch documented in comments rather than having to hack around in files like build_common/SConscript to deduce what is default-on and what isn't). "all the code" covers a lot of ground. what do other projects do? fwiw i've seen a lot of open source code, and i don't recall any (good) ones that take this approach. i'm open to correction, tho. there may be _some_ stuff that should optional in core. like "i don't need fancy onboarding because i'm provisioning everything statically, so i do not want that code in my build". but non-core, vendor-specific stuff is a while nother matter. if i want it, i can link a vendor lib. if not, i would prefer that it not clutter the core source. the cloud stuff is a good example. even better: IPCA. one of infinitely many c++ wrappers on csdk. why on earth is it in master? Things that live out of tree (e.g. separate branches), or which are not built because the options which control them are always off, will never mature and will certainly rot until things will break if you turn them on. hmm. sounds like evolution - a feature, not a bug. code that is useful will be used, code that is not will and should bitrot. _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
