Scripting engine host for applications

Question

We have an application which at certain times needs to execute 'tasks' in order to do some work. These tasks currently are just commands (read: dodgy VB scripts) being fired off and then monitoring the process for completion or aborting if it 'times out', however we don't have enough control over the execution.

I would like to integrate a scripting engine or scripting host to enable us to execute the scripts within our application (in another appdomain if possible) and maintain some control over them. I'd envisage that we have scripts which follow an interface similar to:

void Initialize();
void Destroy();
void Execute();
void Abort();
int GetProgress();

Of course, the above is probably not what would be in the code, however you get the idea... Essentially from our application we could call Initialize, then Execute, poll GetProgress until the return value is 100 or whatever, then at the end either call Destroy or Abort then Destroy if we need to cancel or it goes past the timeout period.

The main thing that the scripts would need to be able to do is AD queries, and interact with the Shell (e.g. Map a network drive, or Disconnect one).

I've looked into a few options to do this - one which I have implemented a prototype of uses Boo as the language and essentially loads the script on the fly to compile and execute as an 'assembly' in memory. I like the way this works but I'm not sure how well it would be accepted not being a 'well known' language etc.

Other options I'm looking at are Python (IronPython), Ruby (IronRuby), PowerShell, and maybe VB, but I'm not sure about the ease of implementation with VB.

Any opinions, comments, suggestions or even resources which might point me in the right direction?

Answer 1

It's not very exciting, but I'd consider using the built in script hosting support. I used to do this in Native C++ with no problem, and .Net seems to have the same thing wrapped (admit the article is old) at http://msdn.microsoft.com/en-us/library/ms974577.aspx

Answer 2

Lua is designed exactly to be embedded in applications. it doesn't hurt that it's a really neat and efficient language.

Answer 3

If you want other people to write scripts for your system, then PowerShell might be a good choice. From my observations, people are less resistant to learning PowerShell than to learning, say, Python. Probably that's because PowerShell comes with the Microsoft stamp of approval. In a Microsoft shop, Python may be seen as too exotic, and Ruby even more so.

It's easy to make the case that everyone in the Microsoft world---be they programmers, QA people, support people, power users---would benefit by learning PowerShell. It's easy to make the case that learning PowerShell would be aligned with their own self-interest. cmd.exe will be obsolete. Everyone will learn PowerShell sooner or later.

That's why I think PowerShell would be a good default choice.

Much of course depends on the particular requirements however.

A good test might be to write a typical script in each of the candidate languages, and see which one is the most natural. It sounds like PowerShell would be a good fit for what you describe. But if the scripts are very "algorithmic", then Python or Ruby would be better. If speed is a requirement, I believe IronPython is much faster than PowerShell. (I don't know about IronRuby.) Etc.

Update: I just had a profound thought :) An embedded scripting language is part of the user interface. That is, it's a UI issue. You should choose which one to use from the user's point of view.