On quinta-feira, 4 de fevereiro de 2016 11:26:09 PST Mitch Kettrick wrote: > Hi, > > Just to add a few points/clarifications to what Ravi has said: > > 1. From a test and certification standpoint, we will be verifying that > read-only Properties cannot be written/updated regardless of the Interface > used. In other words, even though oic.if.baseline supports writing, you > should not be able to update a read-only Property when using it. This will > be checked.
Hello Mitch Thank you, this was implied but is of course good to have it stated explicitly. > 2. Think about a sensor that is asked to send it?s temperature every > second. With oic.if.baseline, the message would looks something like: [cut] > Some clients may be smart enough to use an ?if? query to request > oic.if.baseline the first time and oic.if.s for all subsequent messages. > But not all clients (or their developers) will think from a constrained > device perspective and will be perfectly happy to get the full > oic.if.baseline response every time and only filter out the temperature > value from the entire message. Not good from a battery life perspective. > Allowing the sensor vendor the ability to declare oic.if.s the Default > Interface at least forces Clients to specifically ask for more info (using > and ?if? query for oic.if.baseline) rather than having that be the de facto > message format. Here I disagree with you. First, I disagree that sending a smaller packet will result in battery savings, if a transmission is to happen at all. I may be wrong on my details of how the transceivers work, but I doubt that sending a handful of bytes fewer will affect the consumption at all. So long as the baseline's response don't cause fragmentation and thus the need for multiple packets, the power consumption should be the same. Second, and this is my main point of contention in this discussion, the server's choice in default is meaningless. You said it yourself: "some clients may be smart enough to use an "if" query to request [...] oic.if.s for all subsequent messages". The relevant portion here is that the *client* makes the choice and the server's default was never factored into that decision-making process. So I repeat my argument: having a per-device default is equal to having no default. We may as well abandon the idea of talking about defaults in that case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
