Hi Ravi, 1) Related to the general discussion about ?resource interfaces?, is it reasonable to imagine that the semantics that define the various interfaces are set up so that their application is mutually exclusive to the other interfaces?
If that were true, then A) the mention of an interface name accompanying a resource in the discovery response would simply serve as an absolute declaration of its capabilities, and B) a client would know what kind of requests it can make and what to expect in return. It might further eliminate the need to specify an ?if=x selector in the query. For batch operations, the CoRE specification suggests that when a request propagates below to individual resources, only those methods supported would be executed. So, even if a resource supported multiple interfaces, and their behaviors were mutually exclusive, the response procedure would work itself out. I understood your arguments for calling out a ?default? interface for every resource, but thought that perhaps the answer to the above question was actually the underlying cause for this discussion. 2) The OIC core specification suggests that all resources are to support oic.if.baseline. If a resource then supported oic.if.r, wouldn?t that contradict the baseline interface? Or is it that while implementing a profile, ?assume oic.if.baseline if no other interface is specified?. 3) Your e-mail speaks of a ?composite resource?. Is there a formal definition for it in the core specification? Thanks, -Kishen. On 2/2/16, 5:36 PM, "oswg at openinterconnect.org on behalf of Subramaniam, Ravi" <oswg at openinterconnect.org on behalf of ravi.subramaniam at intel.com> wrote: >Hi Thiago, > >Maybe we are discussing two separate but related topics - what you are >discussing would fall into the pre-requisite category for "default" - >what I am discussing assumes this pre-requisites exist and adding >additional support for runtime/deployment flexibility and for support of >other concepts like Collections. > >So let me try and list what, I think, we agree > >1. Resource Type defines the supported interfaces. >2. As part of discovery, the resource instances and their Resource Types >can be discovered. >3. Post discovery, client knows what Interfaces are supported by the >Resource. >4. Client may choose to use all or a subset of the Interfaces on the >Resource >5. Client may select any Interface using the query in the URI. > >So in effect, once the Device has indicated the Interfaces for the >Resource, the Client drives the selection and use for a transaction. (I >guess this is your argument - no disagreement here). > >The discussion on "default" interface adds one more point to this list >(NOTE: For many situations, the Client could choose to stay with #1 >through #5 but #6 is required for other situations and considerations). > >6. In step 2, the Device/Server also indicates the "default" interface - >which means that if a client issues a request with no query to select the >interface then the server shall interpret that request against the >"default" interface. > >The discussion is on #6. Your point seems to be that lets use #5 only >since one client may use #5 and another may use #6. > >When viewed from a pure "pairwise" point of view i.e. an focus on one >interaction between a single Client and a Server hosting a simple >Resource and then independently focus again on another interaction >between another Client and same Server and Resource, I can see your point >- #6 could be programmer overhead for no gain. > >I think, #6 is not properly understood from this narrow focus. One would >need to take a "systems" view. The benefits may be apparent when looking >at an entire deployment of clients and server like in your home or better >still in a large factory. Here are some scenarios where "default" >interface has value and where being able to specify the "default" >interface at instantiation or deployment of Resource is important: > a. When using the 'batch' interface on a collection - here one can do a >simple GET (with no query) and then get a response from each linked >Resource on its 'default' interface. Requiring the use of queries would >make this very difficult especially if the links are heterogeneous and >expose different interfaces. If a query was required, then "how is one to >specify the interface for each link?". (There is a way with using >"filter" but that would mean parsing expressions against each link when a >default interface could solve that easily.) > b. As the number of Clients increase and the Server say has 100s of >Observe requests - each of these requests need to be cached on the Server >- so from a point of view of Server resources it would be desirable to >not have to store the extra string of "if=<blah>" for each request when >all of these are asking to Observe the most common Interface on that >Resource in that deployment scenario. To make this more concrete - say >these requests are for "sensor" interface since this resource is to be >primarily used as a "sensor" though it also supports the "actuator" >interface. With the query model, every request will have the "if" in the >query when more than 80% of the requests for that deployment are to the >"sensor" interface. By making "sensor" as default, 80% of queries don't >require query parameters. Only if the "actuator" is required, the client >will used "if". Now in another deployment the same Resource Type could >use used on a Resource that is for the most part used as an "actuator" - >in that case the default interface can be made "actuator" so that the >majority of requests will not require the "if" in the query. > c. When using composite Resource i.e. Resources composed of other >Resources like in the case of a Device Resource Type. Allowing the >designer of the Device Resource Type to override or specify the default >interfaces of the standard Resources makes the processing of requests >against this composite Resource easier. > >So I really think we need to take a "systems view" of everything - there >is a danger in focusing only on the protocol or single interaction - OIC >is building an ecosystem and not defining a single protocol. > >Thanks! > >Ravi > >-----Original Message----- >From: oswg at openinterconnect.org [mailto:oswg at openinterconnect.org] On >Behalf Of Thiago Macieira >Sent: Tuesday, February 2, 2016 7:46 AM >To: Subramaniam, Ravi <ravi.subramaniam at intel.com>; >oswg at openinterconnect.org >Cc: iotivity-dev at lists.iotivity.org >Subject: Re: [oswg] Re: [dev] Default interface signaling > >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 >
