On Tue, Aug 14, 2018, 2:59 AM Ondrej Tomcik <ondrej.tom...@kistler.com> wrote:
> 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> > wrote: > > > > On Thu, Aug 9, 2018, 4:04 PM Ondrej Tomcik <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”. > Suggest you think about clearer decoupling. You have quasi-RD functionality, you have data broker (or proxy) functionality, you have "registration" stuff. Shouldn't those be independently specified (and implemetated)? Gregg > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9871): https://lists.iotivity.org/g/iotivity-dev/message/9871 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] -=-=-=-=-=-=-=-=-=-=-=-
