Test. Google Android just disappeared about 3 msgs I just sent. Testing to see if it happens again.
On Sat, Mar 17, 2018, 5:13 PM Gregg Reynolds <d...@mobileink.com> wrote: > > > On Sat, Mar 17, 2018, 5:08 PM Gregg Reynolds <d...@mobileink.com> wrote: > >> >> >> On Sat, Mar 17, 2018, 4:52 PM Heldt-Sheller, Nathan < >> nathan.heldt-shel...@intel.com> wrote: >> >>> Hi Gregg, >>> >>> >>> >>> There’s no reason we need to use svr_cfg.json->whatever.dat model, but >>> whatever we replace it with *does* need to persist the stored values >>> across resets… I can’t tell if your approach (using an app callback to >>> provide a static SVR set) also has a persistent storage plan (e.g. another >>> app callback “save this SVR set and give it to me next time()”)? If not, >>> it needs to. >>> >> Yeah, I looked at that pretty hard. I *think* the initialization logic is >> independent of the persistence logic, but it is sufficiently complicated >> that others would need to confirm. >> >> Yeah, looked at that. I *think* the initialization logic is independent >> of the persistence logic, but that would have to be verified by more >> eyeballs. >> >> So with my static initialization, the initialization is compiled in, no >> need to read/decode a file. But the persistence logic is (I think) >> unaffected. IOW, if a change is made dynamically (PUT or whatever), the >> persistent file still gets written. But it only uses the default file, not >> one named by the app. >> >> Then what happens at restart? Dunno yet, but that should not be hard to >> decide. E.g. if there is a config file, use it, otherwise call the >> user-supplied stuff. >> > > IOW, I am not removing the code that deals with a config dat file, I'm > just not using it for initialization. > > HTH, > > Gregg > >> >> >> One thing I think is a benefit: no more OCF-defined defaults. E.g. reset >> would use the vendor supplied info compiled into the binary rather than >> current hard-coded defaults. >> >> Today or tomorrow I will post a link to my code. >> >> G >> >> >>
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
