Hi Michał, > -----Original Message----- > From: Michał Lowas-Rzechonek [mailto:michal.lowas-rzechonek@xxxxxxxxxxx] > Sent: Wednesday, July 10, 2019 12:53 AM > To: Stotland, Inga <inga.stotland@xxxxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx; Gix, Brian <brian.gix@xxxxxxxxx>; > jakub.witowski@xxxxxxxxxxx > Subject: Re: [PATCH BlueZ 6/9] mesh: Define storage format specific > read/write routines > > On 07/09, Inga Stotland wrote: > > This adds the following generic APIs to mesh-config.h > > void *mesh_config_create_config(void); > > void mesh_config_release_config(void *config); > > void *mesh_config_get_config(const char *dir); > > void *mesh_config_get_config_backup(const char *dir); > > bool mesh_config_restore_backup(const char *dir); > > bool mesh_config_save_config(const char *dir, void *cfg); > > > > The implementation of these API routines depends on the underlying > > storage directory structure and can be specific to a chosen > > configuration file format. > > I don't like the assumption that each node is stored in a separate file, and there > needs to be a backup file. I think I understand what you are saying about *How* the node data is persevered, and that the underlying storage might not be a typical file system. We *do* need a mechanism to get to an earlier version of a Node if there is corruption detected in the most resent version (perhaps an unexpected loss of power during a write operation). That is the purpose of the current backup system. Whether this is accomplished by reading a backup file or "Rolling Back" the history on a journal (or git repo, or whatever) we do need that backup. But we could certainly hide the mechanism of backing up (and of reverting to a backed up version). > One of the storage formats I had in mind is a single transactional database > (some flavor of berkeley db, or maybe even sqlite) that would hold all the > nodes. >
