Plugin Engine

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search

Revision as of 13:02, 18 April 2005

An experimental C#/VB/JScript.NET Script Engine has been committed on the WORLDWIND_1_3_MASHI_SCRIPTCOMPILER branch in CVS.


[edit] Features

  • Dynamic compilation and execution of script code written in the following languages:
    • C#
    • VB.NET
  • Full access to World Wind internals (same as internal code)
  • Runs at full speed (same as an integral part of World Wind)

[edit] Engine logic

When World Wind starts the following steps are performed:

  • The ScriptCompiler scans bin\Plugin directory and the 1st level subdirectories of the plugin directory for files ending in any of the supported file extensions.
  • When it finds one it tries to compile the source (to memory) with references to the same assemblies as the app has referenced.
  • It then searches the compiled assembly for an implementation of IScript.
  • If it finds one it executes InitializeScript().

[edit] Benefits

  • Since the compiler for C#,VB and JSCript comes with the .Net Framework no additional third party library is required.
    • For other languages (like J#) an install will be needed, and unfortunately I haven't found an easy way of enumerating all available compilers (before .Net 2.0)
  • Very fast on-the-fly compilation of the scripts.
  • Scripts executes with same speed as a precompiled assembly.

[edit] Drawbacks

  • Not very debug-friendly (yet), maybe include a working debug project
  • Security: The script could wipe out the hard drive or worse. But with a script at least the user can verify the intentions by looking at the source. Even current add-ons (layers) are often .exe installers giving the user no way of identifying evil code.
  • To unload a script's assembly from memory, WW must be restarted (unless we start messing with appdomains)
  • With no fixed interface into WW the script could break on a new version of WW. But even with an interface the script will break when the interface changes, so in my opinion (Mashiharu) having fixed interfaces will:
    • Give developers a lot of extra work
    • Limit the scripts flexibility
  • Currently no way for scripts to reference other assemblies (third party dlls)
Personal tools