Plugin Engine

From World Wind Wiki

(Difference between revisions)

Jump to: navigation, search

Current revision

A C#/VB/JScript.NET Plugin Engine was added to World Wind in version 1.3.2.

1 Features
2 Engine logic
3 Benefits
4 Drawbacks
5 Problems
6 Security Lockdown Fix
7 Code Translator
8 External links

[edit] Features

Dynamic compilation and execution of script code written in the following languages:
- C#
- VB.NET
- JSCript.net
Load plugins from precompiled .dll files
Full access to World Wind internals (same as internal code)
Runs at full speed (compilation on load)

[edit] Engine logic

When World Wind starts the following steps are performed:

The PluginCompiler scans bin\Plugins 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 Plugin.

[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.
Debuggable inside World Wind project (World Wind in debug build loads internal plugins)
Custom dlls may be dynamically loaded

[edit] Drawbacks

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 completely, WW needs a restarted (there are workarounds (appdomains))
With no nailed down limited interface into WW the script could stop working on a new version of WW.

[edit] Problems

Serializing generic lists (List<SomeClass>) won't work; use a normal array or an ArrayList instead

[edit] Security Lockdown Fix

Following this example we should be able to lockdown FileIO to the AppDir

public static string ReadFile(string filename)
{
  string appDir = Directory.GetCurrentDirectory();
  FileIOPermission f = new FileIOPermission(PermissionState.None);
  f.SetPathList(FileIOPermissionAccess.Read, appDir);
  f.SetPathList(FileIOPermissionAccess.PathDiscovery, appDir);
  f.PermitOnly(); 

  // Use Path.GetFilePath() to canonicalize the file name
  // Use FileStream.OpenRead to open the file
  // Use FileStream.Read to access and return the data
}

From Code Access Security in Practice - MSDN

[edit] Code Translator

C#<->VB [1] So no one can complain about languages. :)

[edit] External links

Retrieved from "https://worldwindcentral.com/wiki/Plugin_Engine"

Category: Plugin development

-An experimental C#/VB/JScript.NET '''Script Engine''' has been committed on the WORLDWIND_1_3_MASHI_SCRIPTCOMPILER branch in [[CVS]].
+A C#/VB/JScript.NET '''Plugin Engine''' was added to World Wind in version 1.3.2.
 ==Features==
 **VB.NET
 **JSCript.net
+*Load plugins from precompiled .dll files
 *Full access to World Wind internals (same as internal code)
-*Runs at full speed (same as an integral part of World Wind)
+*Runs at full speed (compilation on load)
-===Engine logic===
+==Engine logic==
 When World Wind starts the following steps are performed:
-*The [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nasa-exp/WorldWind/WorldWind/Script/ScriptCompiler.cs ScriptCompiler] scans '''bin\Plugin''' directory and the 1st level subdirectories of the plugin directory for files ending in any of the supported file extensions.
+*The [http://cvs.sourceforge.net/viewcvs.py/nasa-exp/WorldWind/WorldWind/PluginEngine/PluginCompiler.cs?view=markup PluginCompiler] scans '''bin\Plugins''' 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 [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nasa-exp/WorldWind/WorldWind/Script/IScript.cs IScript].
+*It then searches the compiled assembly for an implementation of [http://cvs.sourceforge.net/viewcvs.py/nasa-exp/WorldWind/WorldWind/PluginEngine/Plugin.cs?view=markup Plugin].
-*If it finds one it executes InitializeScript().
 ==Benefits==
 *Very fast on-the-fly compilation of the scripts.
 *Scripts executes with same speed as a precompiled assembly.
+*Debuggable inside World Wind project (World Wind in debug build loads internal plugins)
+*Custom dlls may be dynamically loaded
 ==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)
+*To unload a script's assembly from memory completely, WW needs a restarted (there are workarounds (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 ([[User:Mashiharu|Mashiharu]]) having fixed interfaces will:
+*With no nailed down limited interface into WW the script could stop working on a new version of WW.
-**Give developers a lot of extra work
-**Limit the scripts flexibility
-*Currently no way for scripts to reference other assemblies (third party dlls)
-[[Category:Dev]]
+==Problems==
+*Serializing generic lists (List<SomeClass>) won't work; use a normal array or an ArrayList instead
+==Security Lockdown Fix==
+Following this example we should be able to lockdown FileIO to the AppDir
+ public static string ReadFile(string filename)
+ {
+   string appDir = Directory.GetCurrentDirectory();
+   FileIOPermission f = new FileIOPermission(PermissionState.None);
+   f.SetPathList(FileIOPermissionAccess.Read, appDir);
+   f.SetPathList(FileIOPermissionAccess.PathDiscovery, appDir);
+   f.PermitOnly();
+   // Use Path.GetFilePath() to canonicalize the file name
+   // Use FileStream.OpenRead to open the file
+   // Use FileStream.Read to access and return the data
+ }
+From [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp Code Access Security in Practice - MSDN]
+==Code Translator==
+C#<->VB [http://www.carlosag.net/Tools/CodeTranslator/Default.aspx]
+So no one can complain about languages. :)
+==External links==
+[[Category:Plugin development]]