Thiago, The reason is primarily MTU which given some of the radios we need to target can be pretty small. When considering battery is is not a consideration on a per request or response but when one begins to add extra bytes over time then it does make a difference (remember many IOT devices are expected to last on a battery for months even a year and beyond; some smoke detectors on the market run on a single battery for their entire useful life) - I would agree that fragmentation is a bigger cause of battery life where a device has to keep radio on longer. (We haven't defined all the power considerations in spec but smaller packets is always good)
On the second point - I understand your point for simple Resources but when we get to Collections and say the batch Interface using queries is complicated for the client to formulate a request. So giving the client having the option of sending a request without a query portion eases things significantly. When a server indicates the default interface all it is telling the Client - "if you send me a request without a query part then I will interpret that request as if you sent it to the Interface I am telling you is my default" - this makes the semantics of a simple no query request explicit, I don't think the Server is forcing use of the default or selecting an Interface for the Client. Now this default is chosen such that a simple request without query would cover the largest kind of requests expected against the Resource. Given this the Core chose a simple mechanism to communicate the default by using ordering in the discovery response; discovery must be done anyway (whether or not we have default) so that the Client can know which Interfaces it can select from. So there is no extra burden to the Client from designating the default - it just makes it easier for Client to formulate a request in *all* cases i.e. cases with Collections. Now if the Client uses the default semantics fully then we get additional benefits like MTU etc. The use of default is no different from a GUI designer for a mobile app putting the buttons most likely to be used by the user on the home page of the app and burying other options deeper in GUI hierarchy. It is still the user's choice but it does make it easier for the user when the screen is simple and the buttons they are likely to use most often are right there in front. Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 > On Feb 4, 2016, at 1:27 PM, Macieira, Thiago <thiago.macieira at intel.com> > wrote: > >> 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 >
