Hi Thiago, 1. The idea of default interface is about being versatile and flexible in allowing an app or solution developer to define default behavior for a resource at deployment or runtime - it would be hubris at best and stupidity at worst for the spec/Iotivity to believe that we understand all situations that OIC may be used. So the more we allow late binding the better. 2. Regarding implementation: all interfaces that a resource type defines has to be implemented anyway - default does not change implementation requirement for all interfaces defined for that resource type - the default interface allows choice of one of these interfaces at instantiation based on which of the defined interfaces will be most used in that deployment (or based on any other deployment/runtime criteria) 3. This conversation may seem like "why not use baseline" but at this time we have not defined many interfaces but we can add to this in future. Other interfaces that apply for many resources are actuator and sensor. 4. If an application designed for the home for the most part reads a sensor many times an hour using sensor interface and "baseline" has been defined as the default interface - it means that either a query has to be each time or the app has to process additional information like 'rt' and 'if' that is returned in every access (we will add more common properties as time goes on so this can be a lot of irrelevant information to be processed over a day of use of that sensor). Now multiply this with other access by other app instances in that environment. 5. Regarding having to do discovery to find the default interface - this is not an issue - one has to do discovery to find the resource *anyway* - so knowing the default interface at the same time that resource is discovered is not any overhead since you would need to know all the supported interfaces anyway before formulating any request that uses interfaces. If one has a request without any interfaces then one is assuming the default interface (so back to the need for default) 6. So there seems to be only downside in defining the default interface to be fixed and predefined - elimination default also does not help. 7. BTW: I do agree that storage or other such considerations are not relevant for this conversation since one needs to store all the supported interfaces so that a client can use them - making the first in that list as default achieves the objective with no additional storage or keys in the resource. 8. IMHO it is important to see how OIC can and will be used - focusing more on ease of implementation over ease and versatility of use can be counter productive and detrimental to adoption.
Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 > On Feb 1, 2016, at 11:03 PM, Thiago Macieira <thiago.macieira at intel.com> > wrote: > >> On Tuesday 02 February 2016 14:38:25 Dwarkaprasad Dayama wrote: >> Option 1 - >> >> Default interface is clearly defined for each resource. Overriding interface >> type is not allowed. >> >> >> Pros - No surprises for a client due to prior knowledge of default interface >> for each resource. >> >> Cons - Higher memory footprint due to storage of default interface >> information for every resource. Spec to become bulky as on new resources are >> added. Spec lose the flexibility advantage to let a resource decide its own >> default interface. > > That's an acceptable solution. I don't see the Con as you described: what > would need to store the default interface information for every resource and > why? The way I see it, no one needs to store anything. Can you explain where > storage would be necessary? > > The spec becoming bigger is not a problem. This is just an extra definition > for > each interface type. > >> Option 2 - >> >> Single or Common default interface for all resources. Overriding interface >> type is not allowed. >> >> Pros - Fixed memory footprint and easy to maintain. No surprises for client >> due to only 1 interface type to be handled for all resources. >> >> Cons - Constraint devices & network to have trouble if selected interface >> sends more than required data. Spec becomes bounded and no scope of >> extension when new resources or verticals are added. > > This is also an acceptable solution. I again don't understand what the Cons > are. Let's say the default for everything is oic.if.baseline: what kind of > resource type would have a different interface that produces less data? > Please > make sure to answer with a resource type likely to be implemented by a > constrained device -- a group resource isn't. > >> Option 3 - >> >> Default interface is defined in general or specifically depending on >> resource. Overriding the interface type is allowed. 1st interface listed in >> "if" property value is default interface. >> >> Pros - No need of prior knowledge. Smart way to identify the default >> interface. Small memory footprint. Spec gains flexibility advantage and will >> be lighter even if more resources are added. >> >> Cons - Need strong safe guarding mechanism to make sure there are no >> surprises. Software maintenance becomes tricky as on more resources are >> added. > > I think this is not an acceptable solution. > > Additional Con: since the default interface is unknown without first querying > the device, no one will write code that uses the default interface. > Conclusion: default interfaces are useless and we could just as well remove > them from the spec. > > For that reason, I also dispute your Pro too. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >
