On Thursday 14 January 2016 08:41:40 ??? wrote: > Hello All. Hello JungYong
Sorry for the delay in replying. > As you know, Resource Hosting(RH) already located on iotivity primitive > services. RH is useful service for reduction of thin device's power > consumption. But, start of RH has a problem, so I propose an explicit > method for start of RH to improve it. Please check attached a proposal. > > As is, if thin device want to reduce power consumption, thin device can > implicit requests to RH. This is very simple and easy way. > But, thin device should watch for creation of hosting resource. Can you explain why it should? What's wrong with not watching? That is, what is the problem you're trying to solve. I think I get it, but being explicit of the benefits helps getting the process along. > If thin device can explicit requests, > thin device should find RH, but thin device can know about creation of > hosting resource. I think the latter is more clear method for start of RH. I'm not sure which one is which in your diagram. Should I understand that "Origin Server" is the constrained device that wants to offload its resource to the non-constrained "Resource Hosting"? If so, your proposal is that the constrained device should discover devices capable of RH, then it should publish the state to that device. Correct? I agree with that. In answering someone else's question of what happens if the RH hasn't registered itself yet: the constrained device will not be able to publish any state yet and it should repeat the query #3 (Proposal) after an interval. If you meant the other way around, I don't understand the proposal. Also, as another question in the thread: what's the protocol for updating the state in the RH? Another POST? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
