New config system

Hi all, Later this week I'm going to start looking at doing the configuration for my script, and I'm not sure what the best practice is with the new One-Click system. In particular, what's the relationship between globalconfig and state? Can I store all the configuration in globalconfig, or should that not be modified at "runtime"? Ideally I'd like to avoid having to maintain two sets of state if possible...

I do think treating globalconfig as read-only would be a better practice. That said, if you want to mirror globalconfig in state, you have access to _.extend to do so.

You can leave all the configuration in globalconfig provided you have no complex configuration requirements.  Changes to globalconfig are not persisted so anything you wrote there would be lost on restart of the API Sandbox.  For my purposes, globalconfig is only suitable as a configuration input, but not as a master record.  In particular, I generally want to have more complicated configuration options than would be reasonable to put in globalconfig (consider the dynamic rules system in GroupInitiative).  Additionally, I want to provide a way that configuration can be adjusted at runtime, which means I need to persist in the state.  The globalconfig does provide some assistance here.  Steve added a property for each script's configuration area named 'lastsaved' which contains a timestamp when the script was last saved (which equates to the last time the configuration was adjusted/created/enforced) that can be used to know if a configuration happened in the globalconfig since the last time your script took those settings.  If you look at the current released version of Bump, you can see how I've been using it (look at checkInstall() and checkGlobalConfig()). BTW, it is handy to have globalconfig writable for testing, but I otherwise agree with Brian's sentiment that you don't want to be in the habit of writing to globalconfig with any expectations.