On Sat, Mar 17, 2018, 5:08 PM Gregg Reynolds <[email protected]> wrote:
> > > On Sat, Mar 17, 2018, 4:52 PM Heldt-Sheller, Nathan < > [email protected]> 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 [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
