Plugin Engine

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:02, 18 April 2005 (edit)
Mashiharu (Talk | contribs)

← Previous diff
Current revision (10:58, 30 January 2018) (edit) (undo)
Bull (Talk | contribs)
m (Reverted edits by Monday (Talk); changed back to last version by 209.44.140.22)
 
(21 intermediate revisions not shown.)
Line 1: Line 1:
-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== ==Features==
Line 6: Line 6:
**VB.NET **VB.NET
**JSCript.net **JSCript.net
 +*Load plugins from precompiled .dll files
*Full access to World Wind internals (same as internal code) *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: 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. *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== ==Benefits==
Line 21: Line 21:
*Very fast on-the-fly compilation of the scripts. *Very fast on-the-fly compilation of the scripts.
*Scripts executes with same speed as a precompiled assembly. *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== ==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. *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]]

Current revision

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

Contents

[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

Personal tools