Hello Gregg,
Ondrej Tomcik :: KISTLER :: measure, analyze, inovate From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Monday, August 13, 2018 10:00 PM To: Tomcik Ondrej Cc: Scott King; Max Kholmyansky (m...@sureuniversal.com); iotivity-dev Subject: Re: [dev] OCF Native Cloud 2.0 On Thu, Aug 9, 2018, 10:57 PM Ondrej Tomcik <ondrej.tom...@kistler.com<mailto:ondrej.tom...@kistler.com>> wrote: On Thu, Aug 9, 2018, 4:04 PM Ondrej Tomcik <ondrej.tom...@kistler.com<mailto:ondrej.tom...@kistler.com>> wrote: ... It's the core requirement to observe everything. According to whom? It's certainly not a core requirement for me. Otherwise you can't provide up-to-date resource shadow, what leads to - forward every GET to the device. And this does not make sense. The ability to choose which resources to observe makes perfect sense to me. Hmm, now I am not sure if both of you didn't read it properly, or it's not explained well. One more time. To optimize number of requests (not act just as a proxy and forward each request to the device) you need to have consistent and up to date representation in the OCF Native Cloud. That's true. But who said "optimize number of requests" is a requirement? More to the point I think you mean "minimize", not optimize. Optimization always depends on the specific situation; it's also context-dependent. There are always trade-offs; what's optimal for OCF Cloud is not necessarily optimal for my sensor network. E.g. I do not need to "observe" my temp sensors. You’re right. It’s “minimize”, might be also “optimize” based on the use-case. In fact I might not want my sensor to take a reading unless I explicitly ask for it. Requiring observation in such a scenario is not an optimization, just the opposite, imho. Just to mention, It’s up to you if you will publish the change for observers or not. You might have it completely in your hands, on a device side. Publish only every 5th change, or publish if temperature was change in +-1.0, etc. In fact it simply would not work in your scenario. My sensor only takes a reading when it receives a GET, but that never happens since my GET is intercepted by your cloud thingie. I will think about the possibility to support both scenarios. Direct GET or Observe and “shadow GET”. Furthermore it is not a requirement that every server support observation, afaik. Doesn't your design places a new burden on servers? Burden? There is no burden with observe. You have still one TCP connection, only thing you have is an array per resource where are observers registered (observe token,destination,…) , so each change to resource which is observed is published to the cloud (observer) with the token. I don’t see why it should place a burden on servers. You are just asking the server to inform about each change – where each is very relative and it’s up to the device. Gregg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9859): https://lists.iotivity.org/g/iotivity-dev/message/9859 Mute This Topic: https://lists.iotivity.org/mt/24238274/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
