Storing Settings in Storage

@Wilberforce just posted this at http://forum.espruino.com/conversations/­328364:

How are the boot0,1,2 used? I've not seen any examples that I recall?

I've been thinking about an area to store settings. It could have
general interface with settings and getters, and control things like:

on/off: Telnet mDns Sntp Ble radio Wifi radio

Part of this thinking is around @opichals js implementions of sntp and
mDns. Then the decision to use the native implementions or js versions
would be up to the end user.

Taking this a bit further we could also store board specific settings,
like which pins for LED1 and BTN1. This might minimise some of the
pull requests for "ports" to a new board, which only has minor
hardware differences.

So in the esp8266, you could define Btn1 as D0 and if you add a led,
define what pin it's on,

Other settings like baud rate 9600 vs 115200 and solve that issue too.

I just moved this out of the other thread as this is basically a whole new discussion in its own right...

For .boot0,1,2, check out http://www.espruino.com/Saving - It's a reasonably recent addition, but..

• if you want to define BTN1, all you need to do is add global.BTN1=D0 to .boot0 and you're sorted.
  
• same with serial - just Serial1.setup(...) in .boot0 and you've got your serial port set up how you want it
  
• LCD/OLED? You can add that too.
  
• or with Telnet I guess you just stick the TelnetServer.setOptions() command in there.
  
  

Historically this is basically what we've done. When doing save() the current state (that isn't stored as JS variables) is just reconstructed as JavaScript and written away (as a variable) to be executed again at boot. It's basically what you see if you do something like A0.set();dump() - dump() will show you the JS commands needed to recreate the current state.

This happens with pin/peripheral state as well as Bluetooth.

After all, we have a JS interpreter and functions to set the state - why duplicate all of that work to save and recall it all in a different format, especially when that new format will most likely not be as flexible or well documented as the original JS was?

The current solution of saving to a variable only for save() isn't ideal though - but it would be trivial to save the settings to a new file (a bit like .bootcfg) and maybe have the ability to save just that state without saving the rest of the code.

So from my point of view it's difficult. There are obviously good reasons for stuff like WiFi where you might want to easily change the AP name but not some other settings, but even then it feels of limited utility when the config file is completely undocumented.

IMO a lot of things seem like good ideas but wouldn't really add functionality over just writing the JS, and are basically just using up code space.

About the set/get functionality - we have E.setFlags which are saved and restored with save() as well (via variables again), but it isn't very flexible or extensible. We could add a function that was basically just require("Storage").readJSON(".config").c­onfigItem - however even with that for things like WiFi, the current implementation of readJSON followed by repeated queries of that particular object seems better as it's going to be faster anyway.

Because we can't parse just part of the JSON, I think splitting up the configs into task-specific files for big stuff like WiFi is probably a good idea as well. You don't want to have to use several hundred vars each time a setting needs to be read.