How to create a dynamic plugin - Revision history

MakoBot: Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

2012-03-04T06:37:21Z

Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

MakoBot: Robot: Cosmetic changes

2012-03-04T03:22:20Z

Robot: Cosmetic changes

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T22:52:15Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Justincc at 21:27, 6 May 2011

2011-05-06T21:27:39Z

Ideia Boa at 19:00, 21 May 2009

2009-05-21T19:00:35Z

Mikem at 02:06, 10 March 2009

2009-03-10T02:06:20Z

Mikem: /* How to make your own plugin */

2009-01-27T03:27:18Z

‎How to make your own plugin

Zaki: /* How to make your own plugin */

2008-08-06T06:01:52Z

‎How to make your own plugin

Sempuki: /* Mono.Addin concepts */

2008-07-31T02:24:43Z

‎Mono.Addin concepts

Sempuki: /* Mono.Addin concepts */

2008-07-31T02:24:12Z

‎Mono.Addin concepts

@@ Line 3: / Line 3: @@
 <br />
-'''NOTE: This tutorial now refers to a very old OpenSim and so is only partially useful. See [[IRegionModule]] for something more up to date.'''
+'''NOTE: This tutorial now refers to a very old OpenSimulator and so is only partially useful. See [[IRegionModule]] for something more up to date.'''
 == Quick Start ==
@@ Line 13: / Line 13: @@
 The .NET runtime system has always made reflecting and introspecting of assemblies at runtime very easy to do, making dynamic loading of modules possible with very little effort.
-This has unfortunately lead to a situation in OpenSim where historically module loading was hard-coded and done by hand, using copy-and-paste code. Clearly this is a suboptimal situation.
+This has unfortunately lead to a situation in OpenSimulator where historically module loading was hard-coded and done by hand, using copy-and-paste code. Clearly this is a suboptimal situation.
 Effort was made to find a reusable, cross-platform dynamic assembly loader that could be used as-is, instead of reinventing our own. The only current candidate is Mono.Addins. MS's .NET runtime has its own Addin class, however as of this writing it is not yet implemented in Mono.
@@ Line 61: / Line 61: @@
 A service that can be split into producer/consumer role is called an ''extension''. An extension consists of an ''extension point'' which is essentially a text "path" that give a hierarchical name to the service a consumer requires, and an ''extension node'' which represents an object that can provide that service. If a host asks for the addin(s) corresponding to extension point "/Foo", and an addin extension node claims to implement "/Foo", then the two can be joined to make a functioning whole.
-All OpenSim extension points start at the root "/OpenSim". If you wished to create a new service "Foo", you might choose to name it "/OpenSim/Foo".
+All OpenSimulator extension points start at the root "/OpenSim". If you wished to create a new service "Foo", you might choose to name it "/OpenSim/Foo".
 In operation the consumer of a service, the host, requests that the system load all addins that claim to extend an extension point, and a list is returned to the consumer, who can choose to load any subset of those providers, the addins, into memory.
@@ Line 113: / Line 113: @@
 All loaded plugins can now be found in "loader.Plugins" and used as necessary.
-If that looks like a lot of work, consider that outside of the normal work of splitting a class into interface and implementation, its really mostly just boilerplate, and can be accomplished by just comparing how things are currently implemented within OpenSim.
+If that looks like a lot of work, consider that outside of the normal work of splitting a class into interface and implementation, its really mostly just boilerplate, and can be accomplished by just comparing how things are currently implemented within OpenSimulator.
 == Filtering and Constraining ==

@@ Line 3: / Line 3: @@
 <br />
-'''NOTE: This tutorial now refers to a very old OpenSim and so is only partially useful.  See [[IRegionModule]] for something more up to date.'''
+'''NOTE: This tutorial now refers to a very old OpenSim and so is only partially useful. See [[IRegionModule]] for something more up to date.'''
 == Quick Start ==
@@ Line 72: / Line 72: @@
 The manifest has 3 critical parts
-# Name and Version information <br> this is used to check inter-addin dependencies
+# Name and Version information <br /> this is used to check inter-addin dependencies
-# Filename of assemblies where the consumer interfaces or provider implementations can be found <br> this is needed to know which assemblies must be searched
+# Filename of assemblies where the consumer interfaces or provider implementations can be found <br /> this is needed to know which assemblies must be searched
-# Extension Point path and Fully Qualified .NET Class Name of the consumer interface or provider implementation <br> this is needed to load the actual classes into memory
+# Extension Point path and Fully Qualified .NET Class Name of the consumer interface or provider implementation <br /> this is needed to load the actual classes into memory
 The way to tell a host manifest from an addin manifest is that host manifests will *always* contain an ''isroot=true'' attribute in the <Addin> tag. However this is complicated by the fact that an addin can act as host for another addin in a recursive manner.

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
 <br />

@@ Line 2: / Line 2: @@
 {{Template:Quicklinks}}
 <br />
 == Quick Start ==

← Older revision		Revision as of 19:00, 21 May 2009
Line 1:		Line 1:
		+	__NOTOC__
		+	{{Template:Quicklinks}}
		+	<br />
		+
	== Quick Start ==		== Quick Start ==

← Older revision		Revision as of 02:06, 10 March 2009
Line 1:		Line 1:
		+	== Quick Start ==
		+
		+	See [[Dynamic Plugin Quickstart]] for a (hopefully) short introduction.
		+
	== Current state of Plugin loading ==		== Current state of Plugin loading ==

@@ Line 78: / Line 78: @@
 # Create an extension point to identify that service. Ex: "/OpenSim/LartMe"
 # Create an consumer interface that has the methods needed, and derive it from OpenSim.Framework.IPlugin. Ex: "OpenSim.ILart"
-## If that interface needs a constructor that takes parameters, you will also have to create a class derived from PluginInitialzerBase that can act as a [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] for calling a parameterized constructor. See IApplicationPlugin for an example. Ex: "OpenSim.LartInitializer"
+## If that interface needs a constructor that takes parameters, you will also have to create a class derived from PluginInitialiserBase that can act as a [http://en.wikipedia.org/wiki/Closure_(computer_science) closure] for calling a parameterized constructor. See IApplicationPlugin for an example. Ex: "OpenSim.LartInitializer"
 # Write a provider class that implements that interface. Ex: "OpenSim.LartPlugin"
 # Write a host manifest. See OpenSim.addin.xml as an example.

@@ Line 97: / Line 97: @@
 ## If the provider requires a Initializer, it should be passed to the PluginLoader constructor. All plugins will be initialized using this initializer. Ex: "new PluginLoader <ILart> (new LartInitializer ("l4rt"));"
 # Call PluginLoader.Load using the required extension point. Ex: "loader.Load ("/OpenSim/LartMe")"
 All loaded plugins can now be found in "loader.Plugins" and used as necessary.

← Older revision		Revision as of 02:24, 31 July 2008
Line 40:		Line 40:
	Although effort has been made to make PluginLoader independent of the module loading mechanism, there are some concepts that should be understood when learning how to learn the system.		Although effort has been made to make PluginLoader independent of the module loading mechanism, there are some concepts that should be understood when learning how to learn the system.

−	A more detailed (and ''authoritative''!) explanation can be found [http://www.mono-project.com/Mono.Addins_FAQ#Using_Mono.Addins here] and [http://www.mono-project.com/Introduction_to_Mono.Addins here].	+	A more detailed (and '''''authoritative'''''!) explanation can be found [http://www.mono-project.com/Mono.Addins_FAQ#Using_Mono.Addins here] and [http://www.mono-project.com/Introduction_to_Mono.Addins here].

@@ Line 38: / Line 38: @@
 == Mono.Addin concepts ==
-Although effort has been made to make PluginLoader independent of the module loading mechanism, there are some concepts that should be understood when learning how to learn the system:
+Although effort has been made to make PluginLoader independent of the module loading mechanism, there are some concepts that should be understood when learning how to learn the system.
@@ Line 70: / Line 72: @@
 When the PluginLoader is first created within the host, Mono.Addins will search the directory the host was executed and search for all files that end in *.addin.xml. It uses the information to build a ''registry'' about the addins in addin-db-${VERSION}/ directory. The purpose of the registry is to collect all information once, then lazily load assemblies into memory only at the last moment when it is precisely known exactly which class is required by the user.
 == How to make your own plugin ==