Nice work on building an interpreter, but I'd throw the entire SOA book at you for deploying this in a production environment. I haven't even addressed stability, latency and load of programmable Web interfaces, or security.
Nice work on building an interpreter, but I'd throw the entire SOA book at you for deploying this in a production environment. I haven't even addressed stability, latency and load of programmable Web interfaces, or security.
I would like to see some use case thoughts about where this would work better than other alternatives.
Joking aside, why do you think it is any more untestable than any other batch endpoint out there? The concerns you are listing are all valid and can be addressed.
This is more untestable because the service that provides the scripting interface needs to have a test bed that is similar to the test bed of an entire language itself. Are there corner cases? Can a client cause a script to loop indefinitely? Is there a test case for every known combination a client would attempt? If so, why not just support each use case explicitly?
There are 1000 reasons why being additionally clever causes more headaches than its worth. I'm not too upset about it - because I'm confident those that don't heed this warning will learn the lesson the hard way.