Hi Ravi, Thanks for your detailed response. As I stated earlier, I did kind-of/sort-of get where you were coming from. However, if I used a purely non-speculative mindset, I couldn?t tell if the OIC spec was over-analyzing things, or I was under-analyzing. I wasn?t very hung up on the question of having a ?default interface?, but wanted to more generally understand OIC?s definition of resource interfaces. Hence, I posed the questions to seek more clarity.
The CoRE spec defines an interface type as ?An Interface Type definition may describe a resource in terms of it's associated content formats, data types, URI templates, REST methods, parameters, and responses.? My understanding was that an interface type is an absolute property of a resource, much like a resource type, which is implicit in its very nature. It simply exists to provide an expectation to a client of what methods may be executed, their meaning, response type etc. Standardized interface types exist to cover few common and disparate resource categories that make sense architecturally to specify. Executing GET, for eg. on a resource supporting interface x would behave exactly as specified by x, and wouldn?t ever mean something else. In other words, a resource would only expose one interface, the goals being automation and consistency. For eg. a resource exposing oic.if.ll probably only maintains links to other resources and doesn?t/shouldn't provide much else. I couldn?t think of real-world examples, wherein a single physical resource wants to provide two radically different views. If so, I simply assumed that it would get exposed via two separate logical resources. I also considered that for special cases, a user/vendor might support other query parameters, if required, for added specificity inside that whole view that is determined by the interface. This was my own bounded interpretation of the CoRE spec, which seemed logical to me, and where I was coming from to this discussion. It was with this understanding that I spoke of mutual exclusivity of resource interfaces when applied to a resource. That is, it wouldn?t make sense for a resource to support both oic.if.r and oic.if.baseline. The idea that a client could then issue PUT?if=oic.if.baseline and avoid the read-only behavior makes even less sense to me. (I?m glad to hear this might be an error in the OIC spec) Unless my reading of the CoRE spec was incomplete, I can?t help thinking that may be the OIC spec is going beyond CoRE in defining a resource interface, and possibly tending towards a vision that has yet to be fully understood or formulated. Your ?camera mode? analogy certainly makes what you suggest sound more compelling. It would be nice to see some real-world use cases that embody the concept and motivate it. Anyhow, actualizing what you suggest implies that a server supporting multiple varying interfaces must always look out for the ?if? property and provide special implementations of each method over each supported interface. In such a scenario, yes, identifying a ?default interface? might provide a convenience for the reasons you cited. Thanks, -Kishen. From: "Subramaniam, Ravi" <ravi.subramaniam at intel.com<mailto:ravi.subraman...@intel.com>> Date: Tuesday, February 2, 2016 at 10:27 PM To: Kishen Maloor <kishen.maloor at intel.com<mailto:kishen.maloor at intel.com>>, "Macieira, Thiago" <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>, "oswg at openinterconnect.org<mailto:oswg at openinterconnect.org>" <oswg at openinterconnect.org<mailto:oswg at openinterconnect.org>> Cc: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: RE: [oswg] Re: [dev] Default interface signaling Hi Kishen, I am not sure I understand you fully so please excuse if my answers to match your question - will try to answer and hopefully you find some value. Please see inline ... (turned out much longer response than I had initially expected it to be but I hope it helps). Ravi -----Original Message----- From: Maloor, Kishen Sent: Tuesday, February 2, 2016 7:57 PM To: Subramaniam, Ravi <ravi.subramaniam at intel.com<mailto:ravi.subramaniam at intel.com>>; Macieira, Thiago <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>; oswg at openinterconnect.org<mailto:oswg at openinterconnect.org> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [oswg] Re: [dev] Default interface signaling 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? [Ravi: ] An Interface in OIC is *not* to be thought of as an API. A Resource Interface is to be interpreted as a ?view? into a Resource?s representation and what can be done in that view ? similar to how a camera?s lens defines the view; even though the canvas/scene is big, one can only operate on the view that is displayed in the viewfinder; one can select different views of the scene but once the view is selected then one presses the shutter to capture it (i.e. the operation is done after the view is selected) . Two different photographers can select two different views of the scene and say apply different filters, transforms etc to their view i.e. two different Interfaces. Think of the Interface as ?the lens of the camera? ? using a different Interface is using a different lens. Either the dual photographer or single photographer changing lenses does not change the full scene but only what they see of that scene. The camera analogy is like doing a GET on an Interface view ? the Interface view is either the full representation of the Resource or some subset. (Now that I wrote this up ? it might have been better to use the different modes in the iPhone camera ? that is a better analogy for Resource Interface ? each mode defines what can be viewed and what can be done i.e. an Interface ? ?video? defines the size of the view and allows continuous shots, ?photo? mode allows another size of view and allows only shutter press, ?pano? allows a bigger view by panning) This turned out pretty long but hope the analogy helps ? An Interface exposes different parts of the entire representation of a resource (?baseline? provides the entire view). Once a view is chosen/selected then any of the methods (GET, PUT, POST) may, potentially, be used against that view ? so the methods applied are orthogonal to the view selection. The Interface may restrict some of the methods i.e. restrict operation on the view but, again, that is orthogonal to the selection of the view. The mechanism to select an Interface is done using the query parameter ?if=?. So while the views are mutually exclusive, the content of the view are not. This kind of mechanism is not usually seen in the Web world but Interfaces helps a lot in processing complex queries. The methods allowed in the Interface are like ACLs in security and methods in the request are like performing the access ? if the access is permitted by the ACL then only the operation succeeds else it fails. So ?oic.if.r? allows only GET but one could try the following request ?PUT /a/b/foo?if=oic.if.r? ? PUT will be matched against the allowed methods and there will be no match and so this will be an error. Similarly for POST but using GET in the request will match the allowed method in the Interface and the request will succeed. So if a resource supports ?oic.if.baseline? and ?oic.if.r? - ?PUT /a/b/foo?if=oic.if.r? will fail but ?PUT /a/b/foo?if=oic.if.baseline? will work since ?baseline? allows PUT. Same Resource and same method in the request but different outcomes based on chosen Interface. (Disclaimer: It does not make sense for the Resource owner to define both these Interfaces; OIC Core has complicated this situation by defining ?baseline? as mandatory ? this means that by the current spec a Server cannot have ?read only? resources since a Client could then just choose ?baseline? and make the changes it wants. The only way to make this work now is by adding a layer of Security ? for small devices Security is a significant overhead in memory, CPU and power use. Anyway .. that is an issue for discussion another day .. let?s focus on Interface :) ). [Ravi: ] So ? GET /a/b/foo?if=oic.if.ll ? means select the view of the resource /a/b/foo that includes only the value of the ?links? property ? once this view is chosen then apply the GET method on that. (Remember: I have used Resource in all the discussion but, technically, the Interface is defined by the Resource Type ? the Server may choose to expose a subset of the full set defined for that Resource Type and communicates that choice when discovery of the Resource is done ? the Client may then decide to use only a subset of the exposed 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. [Ravi : ] I am not following your point ? A Resource can support more than one Interface i.e. many views can be defined at the same time for a Resource ? so on a discovery all the Interfaces supported by the Resource are returned. I am not sure how a Client would know what requests it could make without selecting a particular Interface ( the method may be known but the Representation is not known). So I am not sure that the ?if=x selector can be eliminated from the query unless there is prior knowledge on what eliminating this query will map to (i.e. default Interface) ? NOTE: The view has to be determined first before the method is applied and using just the URI does not define the view unless we have specified what it means ? this is the use of the ?default interface? ? OIC Core chose ?baseline? as *a* mandatory interface since that is the view into the full representation of the Resource but Core does not say this is *the* mandatory *default* Interface because the full view of the Resource is not the most efficient in all cases. (NOTE: In the Web world, using the full view of the Resource all the time is OK but in IOT when we are dealing with wireless radios with small MTUs, potential congestion, lossy environments etc. it is best to keep the view to the smallest that is useful for that interaction). 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. [Ravi : ] I am not sure CoRE specifies only the ?methods supported? ? I believe that the ?properties? that supported by the list of resources matters as well (the latter is determined by the Interface or view). 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. [Ravi : ] Not sure I understand your conclusion. Could you try once again in light of the explanation I have above? 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?. [Ravi : ] Now that we understand that an interface is a view ? ?baseline? is the entire view of the resource (this Interface supports all the methods), the ?oic.if.r? selects the same view as ?baseline? but restricts the operations to GET. ?baseline? is the maximal view and supports maximal methods; Core defined it as the mandatory Interface and is the fall back when other Interfaces are not defined ? this has issues as above but is how it stands in the Spec today. 3) Your e-mail speaks of a ?composite resource?. Is there a formal definition for it in the core specification? [Ravi : ] Yes, Collections is the method to create ?composite resources? ? the Smart Home Device specification uses this ability of Collections where a Device is a composite resource. Hope this makes sense ? Can you restate your questions if you think they still make sense in light of this response? Thanks, -Kishen. On 2/2/16, 5:36 PM, "oswg at openinterconnect.org on behalf of Subramaniam, Ravi<mailto:oswg at openinterconnect.org%20on%20behalf%20of%20Subramaniam,%20Ravi>" <oswg at openinterconnect.org on behalf of ravi.subramaniam at intel.com<mailto:oswg at openinterconnect.org%20on%20behalf%20of%20ravi.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> >[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<mailto:ravi.subramaniam >at intel.com>>; >oswg at openinterconnect.org<mailto:oswg at openinterconnect.org> >Cc: iotivity-dev at lists.iotivity.org<mailto: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 >
