On Tuesday 02 February 2016 00:45:45 Subramaniam, Ravi wrote:
> Hi Thiago,
Hello Ravi
>
> 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.
I understand that and I get the value you're proposing. I just don't think it
will be used at all because of the reasons I explained before, if each device
can choose its own default. That nullifies the value.
> 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)
I disagree, for the same reason as before: the client (not the server) chooses
which interface it wants to receive from, therefore the choice on the server
is moot or, at best, advisory.
> 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.
That would speak for Dwarka's Option 1 against Option 2, but it does not imply
status quo.
> 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.
If a client is querying a resource in a server, the resource type is fixed by
the server and the interface was chosen by the client. There's no need to
include that information in the reply payload at all, and even if it's
included, there's no need to process it.
> 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)
The overhead is in processing that information and retaining it, and for what
reason? Like I said, the choice of interface belongs to the client, not the
server. The server can, at best, advise which one it thinks the clients should
use, but it cannot enforce that.
Given that the client's application may be coded to work with interface A but
not B or C, it will have to include if=A in the query regardless of which one
the server chose as the default.
At best, the client can be programmed so that *if* the interface it chose is
the default one for that device, it could skip the explicit part in the
payload. But given that another device may not make the same choice, this
would be extra complexity for little gain. It's much simpler to ignore what
the server's choice was and simply pass if=A for all clients.
> 6. So there seems to be only downside in defining the default
> interface to be fixed and predefined - elimination default also does not
> help.
And I argue that having a default in the current terms also has zero benefit.
In other words, all options are equal.
> 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.
I still don't get what you mean by storage.
Do you mean that a client needs to store the list of supported interfaces for
each of the resources it discovered? I disagree then. This storage is either
empty or can be measured in bits:
a) if the client is programmed to use one of the standard interfaces, then
storage is zero. Like you said, all resources are required to implement
all standard interfaces. The client does not need to query the resource to
know what it supports: it supports.
b) if the client is programmed to use an optional interface if it is present
and fall back to a standard one if the optional isn't present, the storage
is one bit.
Note how default never came into the discussion.
> 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.
Agreed, but this is orthogonal.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
