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:[email protected]] 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
