Dear Thiago, Thanks for sharing your opinion. Please find the reply in-lined.
Regards Dwarka ---------------------------------------------------------------------------- ------ Software R&D Center | Software Platform Team | IoT Lab Open Interconnect Consortium - Open Source Work Group Member Iotivity Steering Group - Advisory Committee -----Original Message----- From: oswg at openinterconnect.org [mailto:o...@openinterconnect.org] On Behalf Of Thiago Macieira Sent: Tuesday, February 02, 2016 4:03 PM To: iotivity-dev at lists.iotivity.org Cc: Dwarkaprasad Dayama; oswg at openinterconnect.org Subject: [oswg] Re: [dev] Default interface signaling 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? [Dwarka] If a client wants to query temperature resource of a refrigerator device (refrigerator has 2 temperature resources with same name but different default interface type), it should know if it is actuator or just a sensor. There may be more such cases coming in future. Though we don't have any concept of generic client, but if any member tries to build one, it has to store such information and use GET, PUT or POST depending on what default interface is supported. 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. [Dwarka] Light bulb may send only value of luminance or thermostat may send only value of temperature and not rest of the attributes for that resource, which can save couple of bytes. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160202/e30058a1/attachment.html>
