> Practically, which rule should we apply in this coming release 1.1.0('16
> March)?
Seeing no suggestion coming, allow me to kick the ball here and draft in
initial proposal:
There are different reasons for non-alignment which may require different
rules. So introducing some definitions first will help:
*1) not aligned because non-oic.
*2) not aligned for iotivity backward compatible.
*3) not aligned because oic but still in development.
a) Features aligned with the spec can be put under the oic namespace. i.e. make
it discoverable through res, expose using oic resource types, ... etc
b) All not aligned features (*1, *2, *3) should be behind one (preferably
multiple) enabling compile flag so code is compiled out by default
(preprocessor statements, ...) so vendors can build a minimal oic compliant
image.
This should allow constrained devices to embed a small footprint
Iotivity stack that strictly sufficient to pass oic certification.
c) Features not aligned (*1, *2) should be put under an Iotivity namespace.
i.e. may be discoverable through res but under private namespace using private
resource types, ... etc.
This should allow less constrained devices to embed iotivity backward
compatibility and/or experiment with non-oic features but still pass oic
certification.
d) Features not aligned (*3) may be put oic namespace. i.e. may be discoverable
through res and under oic namespace using oic resource types, ... etc.
This should allow even constrained devices to come to oic plug fests
and test out new oic features vs the compliance test suite under development.
> Let me sum up as follows.
> -IoTivity Base Layer (equivalent to Core Spec area)
> .Most of protocol are aligned to Spec for the base layer from 1.0.1
> ==> it requires the backward compatibility
> .But of protocol are updated after 1.0.1 and will be done soon due to spec
> and open source update and sync. ==> it will break the backward
> compatibility.
> e.g) default interface concept.. which was newly re-defined.. requires API
> break to comply....
The existing implementation fits *2)
=> So I would suggest applying (b) (c) to the existing implementation
The new (re-defined) implementation should initially fit *3) ...
=> So I would suggest applying (b) (d) to the new (re-defined)
implementation
... until proven compliant with the spec (via plugfest with test tool vendor,
...).
=> So it can comply with (a) now. (remove preprocessor statement, ...)
> -IoTivity Service, Security
> Already sync from IoTivity 1.0.1 --> requires backward compatibility.
> Sync updated after IoTivity 1.0.1 or not synchronized --> does not requires
> backward compatibility.
I am not sure how to interpret the or statement in the last sentence here.
Hopefully this gets the ball rolling so people can start shooting...
Best regards,
Stephane.
> BR, Uze Choi
> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
> bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, February 24, 2016 2:42 AM
> To: iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] IoTivity Backward compatibility support level issue.
>
> On ter?a-feira, 23 de fevereiro de 2016 17:37:50 PST ???(Uze Choi) wrote:
> > 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?
>
> Hi Uze
>
> Just to be clear: IoTivity should provide some level of compatibility even for
> non-spec-aligned code, otherwise people can't try out the experimental code.
> I don't think we have a mature enough codebase yet to make long-term
> promises, but we should think about it.
>
> But I agree in principle.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> 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
