Oh. We have presence logic already. By extending this presence logic, we can realized the health check feature also. Currently, there is no mechanism for the client to specifying the TTL when notify back.
Anyway, regarding the additional resource which handle the different logic, I have a negative opinion. Our common (virtual) resource need to be aligned to CoAP specification at least. BR, Uze Choi -----Original Message----- From: Lankswert, Patrick [mailto:patrick.lanksw...@intel.com] Sent: Friday, April 17, 2015 11:17 PM To: Carsten Bormann; "???(Uze Choi)" Cc: junghyun.oh at samsung.com; Samidurai, Sakthivel; Kesavan, Vijay S; kovatsch at inf.ethz.ch; ???; iotivity-dev at lists.iotivity.org Subject: RE: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Carsten and Uze, > -----Original Message----- > From: Carsten Bormann [mailto:cabo at tzi.org] > Sent: Friday, April 17, 2015 4:23 AM > To: "???(Uze Choi)" > Cc: junghyun.oh at samsung.com; Samidurai, Sakthivel; Kesavan, Vijay S; > Lankswert, Patrick; kovatsch at inf.ethz.ch; ???; iotivity- > dev at lists.iotivity.org > Subject: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C > API for multicast presence > > ???(Uze Choi) wrote: > > There is already draft for this in Conditional observe in CoAP. > > https://tools.ietf.org/html/draft-li-core-conditional-observe-02 > > > > How about to implement it into the IoTivity. This will enable various > > usecases. How would you use conditional observe in conjunction with presence? Carsten: Presence is a "push" discovery mechanism. So that devices can notify the network when they become available to the network. > Hi Uze, > > several proposals have been made over the past couple of years for options > that would inform the server about more detailed client requirements for an > observation relationship. None of these gained traction. > > I think the main reason for this was that those details are often very > application specific, and it is hard to generalize them into a small number of > widely applicable options. My original reaction to the parameterized or conditional observation was the same. That is, these are largely application specific behaviors and covering all of the possible use cases would require pulling in an implementation or LUA into the stack. This idea that a resource should have more and more bells and whistles makes the model more and more complex. I would rather have additional resource types that help in these cases to keep basic functionality separate from this robust functionality. In this world, like an adapter pattern, a logical resource is bound to another resource to express the representation that a client of group of clients desires. For example: "Physical" Resource: Temperature Sensor, /temp, rt='com.example.temp', if='s.temp' "Logical" Resource: Hot/Cold, /comfort, rt='com.example.comfort', if="com.example.logical"... The logical resource could be created by clients (or magically by servers) and bound to the temperature resource with the criteria. The logical resource is re-useable by multiple clients who are interested in the same criteria. The logical and physical resource can be on the same or different servers based on device resources available. However, the most important part to me is that the logic for all the conditional logic is handle by the logical resource implementation and not by the CoAP (or HTTP) stack. Does that make sense? > One obvious way to supply additional information is adding query > parameters. What details are supplied can then be controlled by the > application. (The next question, of course, is how the client finds out about > these options -- but that is just an instance of link discovery.) This is workable also. As you say the availability of additional query parameters could be expressed via the interface, or said another way, expressed as part of the function set definition during link discovery. > Now I haven't read the entire thread yet so I don't know how this aspect > relates to the "multicast" in the subject. Will find out later... > > Gr??e, Carsten
