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. 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
