Hi Way, That?s great! I will look into it your changes. It looks rather large.
Do you see (just a yes or no will suffice) a way to tie in hooks on this logic, such that we could implement a way to tell peers that this device is going suspend? Tell me, when you suspend OCProcess, do you also suspend CAProcess()? If so, do you stop all calls to any networking threads in the CA layer? I ask because the CA Layer is multi-threaded. Thanks, Joey Morrow From: Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com<mailto:[email protected]>> Date: Friday, June 30, 2017 at 11:17 PM To: Joseph L Morrow <joseph.l.morrow at intel.com<mailto:joseph.l.morrow at intel.com>>, "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: RE: [dev] Suspend IoTivity Stack? With regards to suspending the stack, I have a patch out at https://gerrit.iotivity.org/gerrit/#/c/18277/ that purposes deprecating OCProcess altogether to allow app suspension. The patch was done some time ago so it needs a rebase, but it should be mostly complete. Unfortunately I had to put the work on hold for other priorities, but you?re most welcome to pick it up if you?d like. Thanks, Way From: Morrow, Joseph L<mailto:[email protected]> Sent: Friday, June 30, 2017 8:28 PM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Suspend IoTivity Stack? Furthermore, I believe it may behoove us to implement a way to suspend the IoTivity stack. This should do 3 things: 1. In the C SDK, and all other higher level SDKs, it should tell the CA Layer to process all of its buffers (while returning some new ?OC_EH_SUSPENDING? to any incoming requests/responses) (I.e. call CAProcess() until no more contents in buffer) 2. In the C++ SDK and all other higher level SDKs (excluding C SDK), it should tell the C SDK to process all of its buffers (I.e. call OCProcess() one last time to process remaining buffer contents). 3. ?Perhaps? On Client side, it would unobserve and unsubscribe to any observe/presence updates before suspending. Then upon resuming, it would re-observe (and map to the app?s same onObserve callback), and similarly for Presence. This would be intended to cover cases a platform goes to deeper sleep (S3). Right now, the CA Layer monitors Network events, but not System sleep events. This would leave platform-specific sleep handling to the Application layer, but letting the IoTivity stack properly keep state and resume automatically. This would also let IoTivity peers to book-keep correctly as this platform will not be responding to incoming requests/responses, but that it will come back. Perhaps this goes back to Suspending/Resuming sessions. Think of Resuming/Suspending a session at your office vs. Resuming/Suspending a session at your home. Your cell phone IoTIvity app (of the future) should be as graceful in those networks as it can with any knowledge it may have about it coming and going away. Thanks, Joey Morrow From: Joseph L Morrow <joseph.l.morrow at intel.com<mailto:[email protected]>> Date: Friday, June 30, 2017 at 5:16 PM To: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: New Request Type: PING (Like Get, Put, Post, ...) Hi All, I was wondering if it would be a good a idea to add a Ping request type. Used primarily for development, or technician-level debugging. I?m thinking there should be a lightweight and static way to check if an IoTivity/OCF stack is up and running without doing discovery or a full CRUDN request. +1 this if you think it?s a good idea. If people like it, maybe we can get some support to add it, or discuss ideas. Let me know. Thanks, Joey Morrow -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170701/b2a1930e/attachment.html>
