.dat file is a serialized internal runtime configuration, it isn't a direct conversion from json to cbor.
--------- Original Message ---------
Sender : Mats Wichmann <[email protected]>
Date : 2018-03-05 19:04 (GMT+2)
Title : Re: [dev] .dat files not being .gitignored?
On 03/05/2018 09:52 AM, Philippe Coval wrote: > > > On 03/05/2018 03:31 PM, Wouter van der Beek (wovander) wrote: >> Sounds like an issue.. > to be reported ;) >> The python works great for creating the introspection files as part of >> the DeviceBuilder tool chain and works fine with the CTT. >> I have tried to use exactly the same sequence for the security files, >> but I never got that to work... not sure what is different and why it >> should be different. >> > > Python tool will be welcome for sure, but I will not recommend to use it. > Relying on 2 implementations to produce .dat files is subject to > inconstancies > we already faced this in the past (and still today), when all .dat files > were not updated after changes. keeping two impls in sync is not great, but on the other hand, it's also nice to have a cross-check: if I modify (A), does it still generate the same as (B) - if not, either the change introduced a bug or (B) needs updating, too. > Also something which is bugging me is that some dats files are modified > once tests are run, and spotted as different, > maybe we should avoid to touch .dat files in tree after they generation. yes, on the security side, dat files represent an svr and if the objective of the test is to update the svr, then the file is modified in place, which means it should be discarded after use. presumably that only happens in /out; my observation is that at least some of the tests make a run-time copy in the top directory (and those files are indeed git-ignored) so they don't modify in place. we can solve all of this if people are motivated to spend a little bit of time on it - a common approach (if one does not already exist) would not be hard to implement once agreed on. _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
Best regards,
Aleksey Volkov
|
|
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
