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.
Thanks, Nathan From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Saturday, March 17, 2018 10:16 PM To: Mats Wichmann <m...@wichmann.us> Cc: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com>; iotivity-dev <iotivity-dev@lists.iotivity.org> Subject: Re: [dev] .dat files not being .gitignored? On Mon, Mar 5, 2018, 6:48 AM Mats Wichmann <m...@wichmann.us<mailto:m...@wichmann.us>> wrote: following on from Phil, the underlying issue is since json2cbor is a binary generated during the build, it does not work at build time for cross builds (host != target, think android in particular). thus a set of checked in dat files is needed. in master, currently, after a .dat is generated to out it is copied back to the src tree specifically so that git status will tell us something is out of sync. that may not be optimal, people are free to suggest better answers. Get rid of the dat files altogether? AFAIK they are only there to bootstrap SVR config at initialization time. Might as well just compile that in at build time, no? I threw together a simple PoC that initializes the doxm resource from a C file and it seems to work (very light testing). Very simply: InitDoxmResource calls get_vendor_doxm (instead of reading and parsing a dat file), which must be implemented by the application to return a ptr to a doxm struct that is assigned to gDoxm. The implementation is dead simple, just static initialization of a struct. Not much more complicated than the JSON. A more dev-friendly implementation would generate the C source from JSON (or as I prefer EDN). Before I put more time in this (other SVRs are more complicated) I'd like to get some feedback. Is there any reason this would not work? I can't find one, but that doesn't mean there isn't one. Gregg
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
