I’m working on the Harvester-AdKiller version 2 recently. Version 2 dropped the idea “Code as Configuration”, because the nature of Chrome Extension. Recompiling and reloading the extension every time when configuration changed is the pain in the ass for me as an user.
new Function('code'). So that it become almost impossible to edit code as data, and later applied it on the fly.
Thanks to the version 1, the feature and DSL has almost fully settled, little updates needed in the near future. So I can use a less flexible language as the DSL instead of CoffeeScript.
Finally I decided to replace CoffeeScript to JSON, which can be easily edited and applied on the fly.
After introducing JSON DSL, to enable DSL upgrading in the future, an migration system become important and urgent. (Actually, this prediction is so solid. I have changed the JSON schema once today.) So I come up a new migration system:
Upgrader will be instantiate when extension started, after
Configuration is initialized, which holds the DSL data for runtime usage.
execute method is invoked, it check the current version, and check is there a upgrading method match to this version. If yes, it triggers the migration; otherwise it succeed the migration. Each time a migration process is completed, it re-trigger
execute method for another round of check.
Adding migration for a specific version of schema is quite simple. Just as method
1.0 does, declaring a method with the version number in the
'undefined' method is a special migration method, which is invoked there is no previous configuration found. So I initialize the configuration from seed data json file, which is generated from the version 1 DSL.
The seed data generation is also an interesting topic. Please refer to next post(Redfine DSL behavior) of this series for details.