Hi Thiago, I understand your point - I missed the email where you replied to Mitch and thanks for repeating it here.
1. I think in the current spec there is nothing that prevents a Client from choosing its own Interface and this can be done with the 'if' query parameter as you have pointed out - I suggested this for the compromise position. Iotivity Clients can ignore the default and use only queries. Furthermore Iotivity can choose to set the "default" as 'baseline' or anything else and move on. This would still be spec compliant. 2. The OIC Device/Server is the Authority of the Resource and as everything else is able to choose its "default" Interface. The default Interface is by Resource and not by Device. The use of default by Client is not mandatory but it is mandatory for the server to indicate a default on Resource discovery. So there is no need for the Client to use the "default" - all default says that semantics of a request without using query parameters implies the interface set as default is used. I am trying to understand the "red herring" concern 3. The default is useful in the case of "batch" Interface. When a request is sent to the "batch" Interface that request is forwarded on to the Links in the Collection - at this point we have not defined the "filter" parameter and so one cannot filter on the Links. So the way it would work is that the default Interface of the Resources in the link gets invoked (first on the list). The Client can figure out what will be called by doing a "discovery" on the Collection using the "links list" Interface. 4. Also when we get Negotiation defined in the Spec, the Client can have a say in choice of default. I am not sure that we want to give up on default just yet. I hope the compromise in #1 above works for you. Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 > On Feb 5, 2016, at 9:14 AM, Macieira, Thiago <thiago.macieira at intel.com> > wrote: > >> On quinta-feira, 4 de fevereiro de 2016 16:50:11 PST Subramaniam, Ravi wrote: >> 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. > > Hello Ravi > > I understand what you're saying, but I will repeat here what I told Mitch: I > don't think the default of the server will factor into the client's decision > making of which interface to use. > > If the client supports parsing interfaces A, B and C, and the server supports > interfaces A, B and D, it's clear that the communication will be handled via > either A or B. Moreover, the *client* chooses which interface to use when > querying. > > Since the default can be either A or B, depending on the manufacturer, > firmware > version, boot order, or the phase of the moon (think of a salted hash), it's > simpler logic for the client to always pass ?if=A and ?if=B when it wants > that > one. It will never rely on the default. > > So I repeat what I said: making the default vary from device to device is, at > best, a zero gain in having a default at all, and at worse it's a red herring > causing confusion. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >
