Thiago/Stephane, (Stephane, Sorry for late response) If we think about the C++ and Java API, different name space looks good idea.
Whatever name-space strategy we use, this looks consensus. : After spec-aligned, API should be backward compatible, Before spec-aligned, API does not require backward compatible. Any issue with it? BR, Uze Choi -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Tuesday, February 23, 2016 9:02 AM To: iotivity-dev at lists.iotivity.org Cc: Stephane Lejeune (stlejeun); ???(Uze Choi) Subject: Re: [dev] IoTivity Backward compatibility support level issue. On quinta-feira, 18 de fevereiro de 2016 10:43:23 PST Stephane Lejeune (stlejeun) wrote: > One option could be: > Use different API name spaces (ex OIC name space and private > namespace) during the ?GAP? period. i.e. :The spec feature gets > developed in the OIC namespace, the open source gets developed in a private > namespace. > Once the > spec and open source have converged for the specific feature, plug the > open source feature into the OIC API namespace. Whether (and how long) > the open source (or a product) wants to maintain the private > namespace (now legacy) becomes then an Iotivity (or product) choice. > What?s important is that the open source allows those options (through > a compile flag) so constrained devices can compile out the legacy overhead > (when appropriate). > > Pro: no API breaks while the feature matures (as spec and open source > play in different name spaces). > > Con: there is still some API breakage when the private API gets > dropped (but that becomes a Iotivity/product choice). I think this is a good idea and a good way to proceed. Of course, we have limited use of the "OIC" namespace (a lot of things were "OC" before). And since we may want to rename to OCF now... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
