We have a key-value store implementation (./internal/kvstore with model in ./internal/model) that is based either on memory or the file system, with a simple API allowing you to get and set "keys" with []byte "values". The most common use case is getting and setting the engine state using the file system ($HOME/.ooniprobe/engine). However, it is increasingly occurring to me that I would like this interface to have "more powers" including probably the possibility of having subdirectories. While it would be possible to implement this functionality in the existing kvstore, it is also useful to consider a possible alternative, well-written backend with more functionality. To this end, the afero.NewBasePathFs constructor seems a possible interesting candidate.
We have a key-value store implementation (
./internal/kvstorewith model in./internal/model) that is based either on memory or the file system, with a simple API allowing you to get and set "keys" with[]byte"values". The most common use case is getting and setting the engine state using the file system ($HOME/.ooniprobe/engine). However, it is increasingly occurring to me that I would like this interface to have "more powers" including probably the possibility of having subdirectories. While it would be possible to implement this functionality in the existing kvstore, it is also useful to consider a possible alternative, well-written backend with more functionality. To this end, theafero.NewBasePathFsconstructor seems a possible interesting candidate.