<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://opensimulator.org/skins/common/feed.css?303"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://opensimulator.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MoHax</id>
		<title>OpenSimulator - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://opensimulator.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MoHax"/>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Special:Contributions/MoHax"/>
		<updated>2026-04-04T22:50:44Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.19.9</generator>

	<entry>
		<id>http://opensimulator.org/wiki/User:MoHax</id>
		<title>User:MoHax</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User:MoHax"/>
				<updated>2010-11-11T06:47:20Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Former contributor no longer active in project.&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/User:MoHax</id>
		<title>User:MoHax</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User:MoHax"/>
				<updated>2010-11-11T06:44:33Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: Removing all content from page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/User_Documentation</id>
		<title>User Documentation</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User_Documentation"/>
				<updated>2008-12-19T17:13:24Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Blogs about OpenSim */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
__NOTOC__&lt;br /&gt;
==Initial Setup==&lt;br /&gt;
* [[Download]] - Download instructions&lt;br /&gt;
* [[Dependencies]] - The other packages you need to install that OpenSim relies upon&lt;br /&gt;
* [[Build Instructions]] - How to build and compile OpenSim from Source&lt;br /&gt;
* [[Configuration]] - How to configure your OpenSim server up and running&lt;br /&gt;
* [[Upgrading]] - How to upgrade your OpenSim version so that you can use your existing data&lt;br /&gt;
* [[Hypergrid]] - Information about how to configure the experimental hypergrid architecture&lt;br /&gt;
* [[Connecting]] - How to connect a compatible viewer to OpenSim&lt;br /&gt;
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.&lt;br /&gt;
* [[Tips]] - Useful tips from users like you&lt;br /&gt;
* [[FAQ]] - Frequently Asked Questions&lt;br /&gt;
&lt;br /&gt;
==Administrator Guide==&lt;br /&gt;
* [[Server Commands]] - Commands to control OpenSim&lt;br /&gt;
* [[OpenSim Database support]] - Dealing with databases&lt;br /&gt;
* [[Logging]] - Logging in OpenSim&lt;br /&gt;
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server&lt;br /&gt;
* [[Automating Tasks]] - How to make administrating a walk in the park&lt;br /&gt;
* [[Network Settings]] - NAT, Ports, Services and more...&lt;br /&gt;
* [[Management]] - All about being an effective administrator/moderator&lt;br /&gt;
* [[Performance]] - How to tweak OpenSim's performance&lt;br /&gt;
* [[Console-less OpenSim]] - How to run OpenSim without console&lt;br /&gt;
* [[GridInfo]] - how to provide information about your grid to smart clients&lt;br /&gt;
&lt;br /&gt;
==Facilities==&lt;br /&gt;
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim&lt;br /&gt;
* [[IRCBridgeModule]] - A core OpenSim module for integrating IRC with a simulator.&lt;br /&gt;
* [[ModRex]] - How to setup the RealXtend server module&lt;br /&gt;
&lt;br /&gt;
==Scripting==&lt;br /&gt;
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting&lt;br /&gt;
* [[Scripting Library]] - A list of example scripts&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
* [http://chapter-and-metaverse.blogspot.com Chapter &amp;amp; Metaverse] - Full suite of tutorials, tips and tricks, for the Windows user (Windows)&lt;br /&gt;
* [[Wiimote]] - How to use a wiimote/nunchuk controller with the Secondlife viewer (Linux)&lt;br /&gt;
* [[Cacti]] - Generate Serverstats using the Cacti-Tool and SNMP (Linux)&lt;br /&gt;
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu (Linux)&lt;br /&gt;
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid&lt;br /&gt;
* [[Hints &amp;amp; Tricks]] - A page for Hints and Tricks&lt;br /&gt;
* [[Getting Started with Region Modules]] - The Hello World of OpenSim application development&lt;br /&gt;
* [[Building a bot]] - Getting started with bot design using libomv from the client side.&lt;br /&gt;
&lt;br /&gt;
==How to make custom terrains==&lt;br /&gt;
&lt;br /&gt;
* [[Using L3DT]] - How to create custom terrains&lt;br /&gt;
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains&lt;br /&gt;
* [http://update.multiverse.net/wiki/index.php/About_Terrain How to make a good Terrain (includes 4 programs to use]&lt;br /&gt;
&lt;br /&gt;
==Gforge Projects==&lt;br /&gt;
* [[OpenSimSearch]] - Search for your OpenSim&lt;br /&gt;
* [[Linux Gridserver]] - Linux Gridserver using the Moo tool&lt;br /&gt;
* [[ServerStats]] - RRD/Proc serverstats using the OpenSim module for Berlios Serverstats (Linux)&lt;br /&gt;
&lt;br /&gt;
==Blogs about OpenSim==&lt;br /&gt;
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSim resources blog post] - a list of resources for running OpenSim&lt;br /&gt;
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc&lt;br /&gt;
* [http://justincc.wordpress.com justincc's blog] - A blog with a weekly OpenSim development update and regular articles on various OpenSim topics.&lt;br /&gt;
* [http://imohax.com Mo Hax] - posts and videos about OpenSim and Second Life from beginner perspective, focus on content previewing and educational use&lt;br /&gt;
&lt;br /&gt;
==Contribution Policy==&lt;br /&gt;
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/User_Documentation</id>
		<title>User Documentation</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User_Documentation"/>
				<updated>2008-12-19T17:10:23Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Blogs about OpenSim */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
__NOTOC__&lt;br /&gt;
==Initial Setup==&lt;br /&gt;
* [[Download]] - Download instructions&lt;br /&gt;
* [[Dependencies]] - The other packages you need to install that OpenSim relies upon&lt;br /&gt;
* [[Build Instructions]] - How to build and compile OpenSim from Source&lt;br /&gt;
* [[Configuration]] - How to configure your OpenSim server up and running&lt;br /&gt;
* [[Upgrading]] - How to upgrade your OpenSim version so that you can use your existing data&lt;br /&gt;
* [[Hypergrid]] - Information about how to configure the experimental hypergrid architecture&lt;br /&gt;
* [[Connecting]] - How to connect a compatible viewer to OpenSim&lt;br /&gt;
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.&lt;br /&gt;
* [[Tips]] - Useful tips from users like you&lt;br /&gt;
* [[FAQ]] - Frequently Asked Questions&lt;br /&gt;
&lt;br /&gt;
==Administrator Guide==&lt;br /&gt;
* [[Server Commands]] - Commands to control OpenSim&lt;br /&gt;
* [[OpenSim Database support]] - Dealing with databases&lt;br /&gt;
* [[Logging]] - Logging in OpenSim&lt;br /&gt;
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server&lt;br /&gt;
* [[Automating Tasks]] - How to make administrating a walk in the park&lt;br /&gt;
* [[Network Settings]] - NAT, Ports, Services and more...&lt;br /&gt;
* [[Management]] - All about being an effective administrator/moderator&lt;br /&gt;
* [[Performance]] - How to tweak OpenSim's performance&lt;br /&gt;
* [[Console-less OpenSim]] - How to run OpenSim without console&lt;br /&gt;
* [[GridInfo]] - how to provide information about your grid to smart clients&lt;br /&gt;
&lt;br /&gt;
==Facilities==&lt;br /&gt;
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim&lt;br /&gt;
* [[IRCBridgeModule]] - A core OpenSim module for integrating IRC with a simulator.&lt;br /&gt;
* [[ModRex]] - How to setup the RealXtend server module&lt;br /&gt;
&lt;br /&gt;
==Scripting==&lt;br /&gt;
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting&lt;br /&gt;
* [[Scripting Library]] - A list of example scripts&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
* [http://chapter-and-metaverse.blogspot.com Chapter &amp;amp; Metaverse] - Full suite of tutorials, tips and tricks, for the Windows user (Windows)&lt;br /&gt;
* [[Wiimote]] - How to use a wiimote/nunchuk controller with the Secondlife viewer (Linux)&lt;br /&gt;
* [[Cacti]] - Generate Serverstats using the Cacti-Tool and SNMP (Linux)&lt;br /&gt;
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu (Linux)&lt;br /&gt;
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid&lt;br /&gt;
* [[Hints &amp;amp; Tricks]] - A page for Hints and Tricks&lt;br /&gt;
* [[Getting Started with Region Modules]] - The Hello World of OpenSim application development&lt;br /&gt;
* [[Building a bot]] - Getting started with bot design using libomv from the client side.&lt;br /&gt;
&lt;br /&gt;
==How to make custom terrains==&lt;br /&gt;
&lt;br /&gt;
* [[Using L3DT]] - How to create custom terrains&lt;br /&gt;
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains&lt;br /&gt;
* [http://update.multiverse.net/wiki/index.php/About_Terrain How to make a good Terrain (includes 4 programs to use]&lt;br /&gt;
&lt;br /&gt;
==Gforge Projects==&lt;br /&gt;
* [[OpenSimSearch]] - Search for your OpenSim&lt;br /&gt;
* [[Linux Gridserver]] - Linux Gridserver using the Moo tool&lt;br /&gt;
* [[ServerStats]] - RRD/Proc serverstats using the OpenSim module for Berlios Serverstats (Linux)&lt;br /&gt;
&lt;br /&gt;
==Blogs about OpenSim==&lt;br /&gt;
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSim resources blog post] - a list of resources for running OpenSim&lt;br /&gt;
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc&lt;br /&gt;
* [http://justincc.wordpress.com justincc's blog] - A blog with a weekly OpenSim development update and regular articles on various OpenSim topics.&lt;br /&gt;
* [http://imohax.com Mo Hax] - posts and video tutorials about OpenSim and Second Life mostly from beginner and content creator perspective, focus on OpenSim for content previewing and educational use&lt;br /&gt;
&lt;br /&gt;
==Contribution Policy==&lt;br /&gt;
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Main_Page"/>
				<updated>2008-11-02T05:07:55Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Using OpenSimulator */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
__NOTOC__&lt;br /&gt;
==Welcome to the '''OpenSimulator Wiki'''.==&lt;br /&gt;
&lt;br /&gt;
=== What is OpenSimulator? ===&lt;br /&gt;
[[image:Opensim_Wright_Plaza.jpg|250px|thumb|right|Wright Plaza on OSGrid]]&lt;br /&gt;
&lt;br /&gt;
OpenSimulator is a 3D Application Server.  It can be used to create a 3D Virtual World (ala [http://www.secondlifegrid.net Second Life(tm)]), and includes facilities for creating custom avatars, chatting with others in the environment, building 3D content in world, and creating complex 3D applications in world.  OpenSimulator can also be extended via [[Region_Modules|loadable modules]] or web service interfaces to build more custom 3D Applications.  OpenSimulator is released under a [[BSD License]], making it both open source, and commercially friendly to embed in products.&lt;br /&gt;
&lt;br /&gt;
Although OpenSimulator is still considered '''alpha software''', many people are [http://technorati.com/search/opensim?authority=a4&amp;amp;language=en doing exciting things with it].  &lt;br /&gt;
&lt;br /&gt;
=== Features ===&lt;br /&gt;
Even though OpenSimulator is realatively young software it already has many useful features&lt;br /&gt;
* Supports creating 1 or more 256x256 meter Regions, either on a single machine, or linked between multiple machines in grid mode&lt;br /&gt;
* Extensive ability to customize you avatar, both with custom clothing, skins, and attached objects&lt;br /&gt;
* The ability to create content real time in the environment using in world building tools&lt;br /&gt;
* Real time physics simulation built on top of the ODE physics library&lt;br /&gt;
* In world application development using a number of different languages, including LSL, C#, and/or Javascript.&lt;br /&gt;
&lt;br /&gt;
=== Using OpenSimulator ===&lt;br /&gt;
The fastest way to get started using OpenSimulator is to create an account on [http://osgrid.org OSGrid], then download the [http://opensim-viewer.sourceforge.net/ Hippo Viewer] or [http://secondlife.com/support/downloads.php Linden Lab's Second Life viewer] (amongst others) to connect to OSGrid.  This process should take no longer than 10 minutes, and will give you a flavor for what OpenSimulator is like.&lt;br /&gt;
&lt;br /&gt;
You can also easily connect to any one of the many [[Grid_List|public grids]] on the internet.&lt;br /&gt;
&lt;br /&gt;
Or you could run a simple standalone OpenSim on your Windows desktop to create and preview content. [http://blip.tv/file/1421954 Here is an eight-minute video showing how].&lt;br /&gt;
&lt;br /&gt;
=== Running your own OpenSimulator ===&lt;br /&gt;
If you are interested in running you own OpenSimulator server, to host your own 3D environments you'll want to check out the following links:&lt;br /&gt;
* [[Download|Getting OpenSimulator]]&lt;br /&gt;
* [[Build_Instructions|Building OpenSimulator]]&lt;br /&gt;
* [[Configuration|Configuring OpenSimulator]]&lt;br /&gt;
* [[FAQ|Frequently Asked Questions in Running OpenSimulator]]&lt;br /&gt;
&lt;br /&gt;
=== Participating in the OpenSimulator Community ===&lt;br /&gt;
OpenSimulator is an [http://en.wikipedia.org/wiki/Open_source open source] project, and is powered by the community members that devote time and energy to the effort.  There are many ways to participate and contribute to the community:&lt;br /&gt;
* Participate via [http://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] - [irc://irc.freenode.net/opensim #opensim] (for users) and [irc://irc.freenode.net/opensim-dev #opensim-dev]&lt;br /&gt;
* Contribute to this wiki, making the OpenSimulator documentation even better.&lt;br /&gt;
* Report Bugs, Submit Patches, or Submit Content contributions via our [http://opensimulator.org/mantis/ mantis bug tracker] (please read our [[Contributions_Policy|Contributions Policy]] prior to submitting patches)&lt;br /&gt;
* Create an OpenSimulator related project hosted on the [http://forge.opensimulator.org Forge] or [http://opensimulator.org/wiki/Related_Software elsewhere] on the web.  In the forge there are over a dozen registered projects, and it's a great way to further extend the OpenSimulator community.&lt;br /&gt;
* Blog about OpenSimulator, and let us know about that blog on [irc://irc.freenode.net/opensim #opensim] so it can be added to [http://planet.opensim.us Planet OpenSim]&lt;br /&gt;
* Participate in one of the weekly [[Office Hours]] for OpenSimulator.  We currently have weekly office hours for development, wiki work, and testing.&lt;br /&gt;
&lt;br /&gt;
''Pages by Category:'' [[:Category:Users|User's Pages]], [[:Category:Development|Development Pages]], [[:Category:Scripts|Scripts]],[[Special:Recentchanges| Recent Wiki Changes]]&amp;lt;br /&amp;gt;&lt;br /&gt;
''Wiki Translations:'' [[OpenSimSpanish | Spanish]], [[OpenSimGerman | German]], [[fr | Francais]], [[OpenSimItalian | Italian]], [[PT| Português]], [http://64.233.179.104/translate_c?hl=ja&amp;amp;langpair=en%7Cja&amp;amp;u=http://opensimulator.org/wiki/Main_Page Japanese]&lt;br /&gt;
[[Category:Main]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Main_Page"/>
				<updated>2008-11-02T05:06:55Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Using OpenSimulator */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
__NOTOC__&lt;br /&gt;
==Welcome to the '''OpenSimulator Wiki'''.==&lt;br /&gt;
&lt;br /&gt;
=== What is OpenSimulator? ===&lt;br /&gt;
[[image:Opensim_Wright_Plaza.jpg|250px|thumb|right|Wright Plaza on OSGrid]]&lt;br /&gt;
&lt;br /&gt;
OpenSimulator is a 3D Application Server.  It can be used to create a 3D Virtual World (ala [http://www.secondlifegrid.net Second Life(tm)]), and includes facilities for creating custom avatars, chatting with others in the environment, building 3D content in world, and creating complex 3D applications in world.  OpenSimulator can also be extended via [[Region_Modules|loadable modules]] or web service interfaces to build more custom 3D Applications.  OpenSimulator is released under a [[BSD License]], making it both open source, and commercially friendly to embed in products.&lt;br /&gt;
&lt;br /&gt;
Although OpenSimulator is still considered '''alpha software''', many people are [http://technorati.com/search/opensim?authority=a4&amp;amp;language=en doing exciting things with it].  &lt;br /&gt;
&lt;br /&gt;
=== Features ===&lt;br /&gt;
Even though OpenSimulator is realatively young software it already has many useful features&lt;br /&gt;
* Supports creating 1 or more 256x256 meter Regions, either on a single machine, or linked between multiple machines in grid mode&lt;br /&gt;
* Extensive ability to customize you avatar, both with custom clothing, skins, and attached objects&lt;br /&gt;
* The ability to create content real time in the environment using in world building tools&lt;br /&gt;
* Real time physics simulation built on top of the ODE physics library&lt;br /&gt;
* In world application development using a number of different languages, including LSL, C#, and/or Javascript.&lt;br /&gt;
&lt;br /&gt;
=== Using OpenSimulator ===&lt;br /&gt;
The fastest way to get started using OpenSimulator is to create an account on [http://osgrid.org OSGrid], then download the [http://opensim-viewer.sourceforge.net/ Hippo Viewer] or [http://secondlife.com/support/downloads.php Linden Lab's Second Life viewer] (amongst others) to connect to OSGrid.  This process should take no longer than 10 minutes, and will give you a flavor for what OpenSimulator is like.&lt;br /&gt;
&lt;br /&gt;
You can also easily connect to any one of the many [[Grid_List|public grids]] on the internet.&lt;br /&gt;
&lt;br /&gt;
Or you could run a simple standalone OpenSim on your Windows desktop to create and preview content. [http://blip.tv/file/1421954 Here is an eight and a half video showing how].&lt;br /&gt;
&lt;br /&gt;
=== Running your own OpenSimulator ===&lt;br /&gt;
If you are interested in running you own OpenSimulator server, to host your own 3D environments you'll want to check out the following links:&lt;br /&gt;
* [[Download|Getting OpenSimulator]]&lt;br /&gt;
* [[Build_Instructions|Building OpenSimulator]]&lt;br /&gt;
* [[Configuration|Configuring OpenSimulator]]&lt;br /&gt;
* [[FAQ|Frequently Asked Questions in Running OpenSimulator]]&lt;br /&gt;
&lt;br /&gt;
=== Participating in the OpenSimulator Community ===&lt;br /&gt;
OpenSimulator is an [http://en.wikipedia.org/wiki/Open_source open source] project, and is powered by the community members that devote time and energy to the effort.  There are many ways to participate and contribute to the community:&lt;br /&gt;
* Participate via [http://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] - [irc://irc.freenode.net/opensim #opensim] (for users) and [irc://irc.freenode.net/opensim-dev #opensim-dev]&lt;br /&gt;
* Contribute to this wiki, making the OpenSimulator documentation even better.&lt;br /&gt;
* Report Bugs, Submit Patches, or Submit Content contributions via our [http://opensimulator.org/mantis/ mantis bug tracker] (please read our [[Contributions_Policy|Contributions Policy]] prior to submitting patches)&lt;br /&gt;
* Create an OpenSimulator related project hosted on the [http://forge.opensimulator.org Forge] or [http://opensimulator.org/wiki/Related_Software elsewhere] on the web.  In the forge there are over a dozen registered projects, and it's a great way to further extend the OpenSimulator community.&lt;br /&gt;
* Blog about OpenSimulator, and let us know about that blog on [irc://irc.freenode.net/opensim #opensim] so it can be added to [http://planet.opensim.us Planet OpenSim]&lt;br /&gt;
* Participate in one of the weekly [[Office Hours]] for OpenSimulator.  We currently have weekly office hours for development, wiki work, and testing.&lt;br /&gt;
&lt;br /&gt;
''Pages by Category:'' [[:Category:Users|User's Pages]], [[:Category:Development|Development Pages]], [[:Category:Scripts|Scripts]],[[Special:Recentchanges| Recent Wiki Changes]]&amp;lt;br /&amp;gt;&lt;br /&gt;
''Wiki Translations:'' [[OpenSimSpanish | Spanish]], [[OpenSimGerman | German]], [[fr | Francais]], [[OpenSimItalian | Italian]], [[PT| Português]], [http://64.233.179.104/translate_c?hl=ja&amp;amp;langpair=en%7Cja&amp;amp;u=http://opensimulator.org/wiki/Main_Page Japanese]&lt;br /&gt;
[[Category:Main]]&lt;br /&gt;
[[Category:Getting Started]]&lt;br /&gt;
[[Category:Development]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Download</id>
		<title>Download</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Download"/>
				<updated>2008-11-01T23:47:33Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Source code */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
==Source code==&lt;br /&gt;
Here are the current released versions of OpenSim.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;font color=red&amp;gt;'''Please note:'''&amp;lt;/font&amp;gt; As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases.  Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet.  However, constructive feedback is still welcomed.&lt;br /&gt;
&lt;br /&gt;
Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up - there is no point and click installer (and having one would probably be premature at this stage).&lt;br /&gt;
&lt;br /&gt;
You may need to use the Subversion source code management system to obtain the code.  For Windows you can install just [http://subversion.tigris.org/servlets/NewsItemView?newsItemID=1941 Subversion] or the often preferred [http://tortoisesvn.tigris.org Tortoise Subversion extension]. Mac OS X 10.l5 and above have Subversion built but OS. X 10.4.x can still [http://homepage.mac.com/martinott/Subversion-1.4.4.pkg.zip download Subversion].&lt;br /&gt;
&lt;br /&gt;
Another option for obtaining the code is via [http://www.selenic.com/mercurial/wiki/ mercurial] from the [http://opensimulator.org/hg/opensim-trunk/ OpenSim repository].&lt;br /&gt;
&lt;br /&gt;
* '''Latest Subversion revision version (bleeding edge)'''&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
&lt;br /&gt;
* '''Latest mercurial revision version (bleeding edge)'''&lt;br /&gt;
 hg clone http://opensimulator.org/hg/opensim-trunk/ opensim&lt;br /&gt;
&lt;br /&gt;
==Binaries==&lt;br /&gt;
&amp;lt;font color=red&amp;gt;'''Please Note:'''&amp;lt;/font&amp;gt; Binary releases not hosted by opensimulator.org are unofficial - they are not endorsed by the core OpenSimulator development team and so we cannot guarantee their authenticity.  If you use them, please don't necessarily expect support from the community, especially if they are older versions than the current version.  At this stage in our development, it is often be the case that many hundreds of revisions have occurred and a number of issues have been fixed since the binaries were released.  Currently, the preferred (and recommended) method to get a working system is to build OpenSimulator from source.&lt;br /&gt;
&lt;br /&gt;
* '''Official Nightly Build Binary (Recommended for quick testing)&lt;br /&gt;
 http://builds.opensimulator.org&lt;br /&gt;
&lt;br /&gt;
* '''Official Build (0.5.11)&lt;br /&gt;
 http://osgrid.org/download/osgrid.opensim.v0.5.11.6676.zip&lt;br /&gt;
&lt;br /&gt;
* '''Official DGP Build (0.5.11)&lt;br /&gt;
 http://built-dgpgrid-org.s3.amazonaws.com/6814.zip&lt;br /&gt;
&lt;br /&gt;
==Addons==&lt;br /&gt;
'''Openlibrary release v0.53''' (Oct 11) is a collection of Texures, Skins, Clothing etc Assets &amp;amp; Inventory Items common to all users when installed to your OpenSimulator Release. This library is provided under Creative Commons 2.5 by Attribution License courtesy of Openlifegrid.com. After install all users will see these items &amp;amp; assets in the Libraries-&amp;gt;Openlibrary root folder.&lt;br /&gt;
* [http://openlifegrid.com/Downloads/tabid/67/Default.aspx Openlifegrid.com Downloads] (1 time registration required) contributions to the library are welcome.&lt;br /&gt;
&lt;br /&gt;
To Use Replace your existing Assets &amp;amp; Inventory Library with the Assets &amp;amp; Inventory Folders contained in the downloaded .zip file.&lt;br /&gt;
*** PLEASE DO NOT ASK THE OPENSIMULATOR TEAM FOR SUPPPORT ABOUT THESE ADD-ON PACKAGES&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]]&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
[[Category:Developers]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Build_Instructions</id>
		<title>Build Instructions</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Build_Instructions"/>
				<updated>2008-11-01T15:26:29Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Ubuntu 8.04 / 8.10 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:Users]]&lt;br /&gt;
This page covers building OpenSim from source code on multiple platforms.  Please help us keep this page up to date as the project progresses.&lt;br /&gt;
&lt;br /&gt;
==Download from SVN==&lt;br /&gt;
Check out the [[Download]] Section&lt;br /&gt;
&lt;br /&gt;
==MS Windows==&lt;br /&gt;
&lt;br /&gt;
OpenSim requires either the .Net framework version 2.0, or the latest Mono. It supports the following compilers:&lt;br /&gt;
* [http://msdn2.microsoft.com/en-us/express/aa700756.aspx Microsoft Visual C# Express Edition] (note: not Visual C++)&lt;br /&gt;
* [http://www.mono-project.com/ mono]&lt;br /&gt;
&lt;br /&gt;
Note for people who just downloaded the sources from http://dist.opensimulator.org/ (the &amp;quot;Downloads&amp;quot; link on the left) be advised that some important things are missing (like MySQL template scripts). For such features, you must download using svn!&lt;br /&gt;
&lt;br /&gt;
Additional note: any Microsoft C# Express edition should work (2005 or 2008)&lt;br /&gt;
&lt;br /&gt;
=== Building ===&lt;br /&gt;
&lt;br /&gt;
* In the top-level directory, run the '&amp;lt;tt&amp;gt;runprebuild.bat&amp;lt;/tt&amp;gt;' file. This will create both a VS2005 solution file, and a nant build file.&lt;br /&gt;
* Open the resulting sln file with visual studio, and build it there, or if you prefer to use nant, run nant in the same top-level directory. This will build the executables.&lt;br /&gt;
&lt;br /&gt;
If you don't care about physics (walking on prims, etc), ignore the rest of this section.&lt;br /&gt;
&lt;br /&gt;
=== Running ===&lt;br /&gt;
&lt;br /&gt;
Recent versions of OpenSim come without an &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file. Copy the &amp;lt;tt&amp;gt;OpenSim.ini.example&amp;lt;/tt&amp;gt; file to &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; before making any changes.&lt;br /&gt;
&lt;br /&gt;
Double-click on the &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; executable file in the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory. This will start up OpenSim in standalone mode.&lt;br /&gt;
&lt;br /&gt;
The debugger in VS2005 C# may be used to step through the code. For those that use a Cygwin shell, you may find that one or more dll's have permissions that cause problems running. Most find that a &amp;quot;&amp;lt;tt&amp;gt;chmod 777 *&amp;lt;/tt&amp;gt;&amp;quot; from the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory solves this.&lt;br /&gt;
&lt;br /&gt;
Physics can be invoked by adding the appropriate line to the [Startup] section of &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt;.  For ODE, that would be:&lt;br /&gt;
&lt;br /&gt;
 physics = OpenDynamicsEngine&lt;br /&gt;
&lt;br /&gt;
You can also add a command line option to a shortcut, or run from a command prompt with:&lt;br /&gt;
&lt;br /&gt;
 -physics=OpenDynamicsEngine&lt;br /&gt;
&lt;br /&gt;
'''''Windows Vista'''''&lt;br /&gt;
&lt;br /&gt;
To run on Windows Vista, you must first disable Windows Firewall.  Under the new &amp;quot;Start&amp;quot; button of Vista, select &amp;quot;Control panel&amp;quot;.  Then double-click &amp;quot;Windows Firewall&amp;quot;.  In the window that pops up, on the left column, select &amp;quot;Turn Windows Firewall on or off&amp;quot;.  You will have to give permission for this to run, then select the option &amp;quot;Off (not recommended)&amp;quot;.  Click &amp;quot;OK&amp;quot; and exit from the Windows Firewall window.&lt;br /&gt;
&lt;br /&gt;
If you have McAfee SecurityCenter, see the description below.&lt;br /&gt;
&lt;br /&gt;
Once all the security features are disabled, right click on &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; and select &amp;quot;Run as administrator&amp;quot;.  This will pop up a window asking permission, select &amp;quot;Allow&amp;quot;.  Your OpenSim server should run in a DOS-like window and accept connections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''McAfee Security'''''&lt;br /&gt;
&lt;br /&gt;
McAfee Security does not allow applications to listen on ports not explicitly specified.  You have two options: 1) disable firewall protection all together, 2) enable &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; to be able to open ports.&lt;br /&gt;
&lt;br /&gt;
''Disable firewall''&lt;br /&gt;
&lt;br /&gt;
Open McAfee SecurityCenter.  Select &amp;quot;Internet &amp;amp; Network&amp;quot;.  In the lower left corner is a small link to &amp;quot;Configure...&amp;quot;.  Select this.  In the right side of the window, select the bar that says &amp;quot;Firewall protection is enabled&amp;quot;.  Here you can select &amp;quot;Off&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
''Enable &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; to open ports''&lt;br /&gt;
&lt;br /&gt;
Open McAfee SecurityCenter.  Select &amp;quot;Internet &amp;amp; Network&amp;quot;.  In the lower left corner is a small link to &amp;quot;Configure...&amp;quot;.  Select this.  In the right side of the window, select the bar that says &amp;quot;Firewall protection is enabled&amp;quot;.  Select the &amp;quot;Advanced...&amp;quot; button.  This will pop up a new window.&lt;br /&gt;
&lt;br /&gt;
In the new window, on the left side, select &amp;quot;Program Permissions.&amp;quot;  In the middle on the right side of the window, select the &amp;quot;Add Allowed Program&amp;quot; button.  Use the browser that pops up to find the OpenSim executable and select it.&lt;br /&gt;
&lt;br /&gt;
Finally, select &amp;quot;OK&amp;quot; and exit the McAfee SecurityCenter window.&lt;br /&gt;
&lt;br /&gt;
==Linux/Mac OS X/FreeBSD==&lt;br /&gt;
&lt;br /&gt;
The easiest plaform to get running on the Linux side is Ubuntu 8.04, 32bit.  This is what most of the developers running Linux use.  If you are looking for the quick path, start there.&lt;br /&gt;
&lt;br /&gt;
=== Ubuntu 8.04 / 8.10 ===&lt;br /&gt;
&lt;br /&gt;
For Ubuntu 7.10 users '''you need''' to upgrade your mono to 1.9.1.&lt;br /&gt;
&lt;br /&gt;
You can use the built in packages for mono.  However, for better performance, you may want to [http://xyzzyxyzzy.net/2008/05/08/updated-mono-build-script-for-hardy-heron-and-mono-191/ upgrade mono to 1.9.1] ([http://tempvariable.blogspot.com/2008/04/installing-mono-191-on-ubuntu-804-hardy.html Other simple method])&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install subversion nant mono-gmcs libmono-microsoft8.0-cil \&lt;br /&gt;
      libmono-system-runtime2.0-cil libgdiplus libmono-i18n2.0-cil ruby&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
=== openSUSE 10.3 and 11 ===&lt;br /&gt;
&lt;br /&gt;
Install an openSUSE 11 or 10.3 with its default options, add the online repositories&lt;br /&gt;
when finished installing do an online update with all the latest packages.&lt;br /&gt;
&lt;br /&gt;
In yast install these packages, for running Opensim in standalone mode.&lt;br /&gt;
(there is a slight diffrence between 10.3 and 11 but following should be same)&lt;br /&gt;
 subversion&lt;br /&gt;
 nant&lt;br /&gt;
 mono-jscript&lt;br /&gt;
 - check that mono-core is installed&lt;br /&gt;
&lt;br /&gt;
If you just want to use SQLite then jump to last section &lt;br /&gt;
within this post.&lt;br /&gt;
&lt;br /&gt;
* Optional mysql - for Opensim running in Grid mode:&lt;br /&gt;
Install these mysql packages via yast&lt;br /&gt;
  mysql&lt;br /&gt;
  mysql-client&lt;br /&gt;
  mysql-administrator&lt;br /&gt;
  mysql-gui-tools&lt;br /&gt;
  mysql-query-browser&lt;br /&gt;
&lt;br /&gt;
Before building create the mysql database.&lt;br /&gt;
 /etc/init.d/mysql start&lt;br /&gt;
 mysql -u root -p -h localhost&lt;br /&gt;
 (when asked for password just hit enter)&lt;br /&gt;
&lt;br /&gt;
 mysql&amp;gt; create database opensim;&lt;br /&gt;
 mysql&amp;gt; quit&lt;br /&gt;
&lt;br /&gt;
set the configuration in bin/mysql_connection.ini&lt;br /&gt;
Or on later builds set the connection string inside bin/OpenSim.ini&lt;br /&gt;
&lt;br /&gt;
Build after installation of above in bash terminal. i save it in /opt&lt;br /&gt;
&lt;br /&gt;
 su -&lt;br /&gt;
 cd /opt&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
After this you should be able to continue on starting the diffrent Servers, look in the mysql-config section,or&lt;br /&gt;
just run your OpenSim as a Standalone. By - eagleFX&lt;br /&gt;
&lt;br /&gt;
=== Mac OS X 10.5/10.4 ===&lt;br /&gt;
* OpenSim is now working on PowerPC Macs! Thanks to DrScofield and those who helped him. Current nightly builds for PowerPC are not working, not sure about Intel so use the 0.5 Build. OpenSim works on Intel Macs. I'm testing on PowerBook G4. Tested these step on 10.5, but not 10.4 but should work --[[User:Mokele|Mokele]] 22:36, 14 February 2008 (PST)&lt;br /&gt;
* Install XCode Developers Tools from DVD/CD Installation Disk or download  from http://developer.apple.com/. You have to create an Apple account to access the downloads if you don't have an Apple account.&lt;br /&gt;
* Install X11 for 10.4 from the Optional Install from the DVD/CD Installation Disk. X11 for 10.5 is installed by default.&lt;br /&gt;
* Install Mono 1.2.5 from http://ftp.novell.com/pub/mono/archive/1.2.5/macos-10-universal/5/MonoFramework-1.2.5_5.macos10.novell.universal.dmg and in Terminal or X11 edit the .profile file  and add the following line:&lt;br /&gt;
 export PKG_CONFIG_PATH=&amp;quot;/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/:${PKG_CONFIG_PATH}&amp;quot;&lt;br /&gt;
* Compile OpenSim&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/tags/0.5.0-release opensim&lt;br /&gt;
 cd opensim &lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
* Download and Compile libopenjpeg-libsl-2.1.2.0.dylib and libsecondlife.dll&lt;br /&gt;
* libopenjpeg-libsl-2.1.2.0.dylib:&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs&lt;br /&gt;
 cd opensim-libs/openjpeg-libsl&lt;br /&gt;
 make -f Makefile.osx&lt;br /&gt;
 cp libopenjpeg-libsl-2.1.2.0.dylib ../../opensim/bin&lt;br /&gt;
* Note: The Makefile that creates the libopenjpeg-libsl-2.1.2.0.so does not compile on PowerPC, but works properly on Intel Macs. Looks like a gcc issue with compile options.&lt;br /&gt;
&lt;br /&gt;
* libsecondlife.dll: (for PowerPC Only, see  details on this step [http://xyzzyxyzzy.net/2008/02/12/installing-opensim-on-powerpcor-of-eggs-and-virtual-worlds installing OpenSim on PowerPC…or: of eggs and virtual worlds])&lt;br /&gt;
 cd .. (back into opensim-libs)&lt;br /&gt;
 nant&lt;br /&gt;
 cp bin/libsecondlife.dll ../opensim/bin&lt;br /&gt;
&lt;br /&gt;
* Edit the libsecondlife.dll.config (PowerPC Only). Remove the cpu=&amp;quot;x86&amp;quot; tag in the last dllmap line.&lt;br /&gt;
&lt;br /&gt;
=== FreeBSD 6.2 ===&lt;br /&gt;
 su&lt;br /&gt;
 cd /usr/ports/devel/subversion/ &amp;amp;&amp;amp; make install clean (you may also need to rebuild apr-svn if this step fails)&lt;br /&gt;
 cd /usr/ports/lang/mono/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/devel/nant/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/databases/sqlite3/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/x11-toolkits/libgdiplus/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /opensim/installation/directory/&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
 Note: [http://opensimulator.org/wiki/OpenSim:FAQ#System.DllNotFoundException:_..2Flibopenjpeg-libsl-2.1.2.0.so|Follow the instructions on the FAQ to fix the]&lt;br /&gt;
 &amp;quot;System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so&amp;quot; issue, but use &amp;quot;gmake&amp;quot; instead of &amp;quot;make&amp;quot;&lt;br /&gt;
&lt;br /&gt;
For ODE Physics you must do the following:&lt;br /&gt;
 cd /usr/ports/graphics/libGL/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/graphics/libGLU/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /opensim/installation/directory/&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim-libs/trunk opensim-libs&lt;br /&gt;
 cd opensim-libs/unmanaged/OpenDynamicsEngine2/&lt;br /&gt;
 sh autogen.sh&lt;br /&gt;
 ./configure --enable-shared --enable-release --disable-demos&lt;br /&gt;
 make&lt;br /&gt;
 mv ./ode/src/libode.so /opensim/installation/directory/opensim/bin/&lt;br /&gt;
&lt;br /&gt;
=== RedHat Enterprise Linux 4 ===&lt;br /&gt;
 sudo vi /etc/yum.repos.d/mono.repo&lt;br /&gt;
&lt;br /&gt;
  [mono]&lt;br /&gt;
  name=Mono for rhel-4-i386 (stable)&lt;br /&gt;
  baseurl=http://ftp.novell.com/pub/mono/download-stable/rhel-4-i386/&lt;br /&gt;
  enabled=1&lt;br /&gt;
  gpgcheck=0&lt;br /&gt;
&lt;br /&gt;
 sudo yum install mono-complete monodoc-core nant&lt;br /&gt;
 svn co svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
=== Fedora 5 ===&lt;br /&gt;
* I needed to build latest mono and nant from sources to build OpenSim successfully, the ones available in yum repository didn't work so I had to uninstall and build and configure the packages.&lt;br /&gt;
&lt;br /&gt;
For detailed instructions go [http://ruakuu.blogspot.com/2008/06/installing-and-configuring-opensim-on.html here]&lt;br /&gt;
&lt;br /&gt;
=== Debian 4 ===&lt;br /&gt;
&lt;br /&gt;
The following packages and their dependencies are required to run OpenSim on a default Debian 4 netinstall:&lt;br /&gt;
* mono&lt;br /&gt;
* libmono-corlib2.0-cil&lt;br /&gt;
* libmono-sqlite2.0-cil&lt;br /&gt;
* libmono-system-web2.0-cil&lt;br /&gt;
* libmono-microsoft8.0-cil&lt;br /&gt;
* libmono-system-runtime2.0-cil&lt;br /&gt;
&lt;br /&gt;
=== 64bit ===&lt;br /&gt;
Please note that only 32bit binaries are provided in the bin/ directory of subversion.  If you want to use 64bit, you'll need to rebuild these shared objects.  See [[Installing and running on x86-64]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Physics (Open Dynamics Engine ODE) ===&lt;br /&gt;
As installed from svn, ODE will work on most 32 bit platforms.  If you get an ODE-related crash, and/or a &amp;lt;i&amp;gt;libode.so not found&amp;lt;/i&amp;gt; type of error, you will need to build libode from source.&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; from the &amp;lt;tt&amp;gt;./bin&amp;lt;/tt&amp;gt; folder.  (Note that subsequent svn updates may replace it again; best fix is to copy your built &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; to &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt;).  Do NOT remove &amp;lt;tt&amp;gt;ode.net.dll&amp;lt;/tt&amp;gt;!  Download the latest source from:&lt;br /&gt;
&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim-libs/trunk/unmanaged/OpenDynamicsEngine2&lt;br /&gt;
&lt;br /&gt;
OpenSim requires a couple of patches on top of ODE which are not yet included upstream.  When compiling, make sure to use the following configure options:&lt;br /&gt;
&lt;br /&gt;
 --with-trimesh=gimpact &lt;br /&gt;
 --enable-shared&lt;br /&gt;
&lt;br /&gt;
Make sure the configure script confirms these choices, and always compile with single precision (I believe that's the default).  Try &amp;lt;code&amp;gt; make -k &amp;lt;/code&amp;gt; if you get errors relating to drawstuff, test*, or openGL.  &amp;lt;code&amp;gt; make install &amp;lt;/code&amp;gt; should put &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; in the proper place (usually &amp;lt;tt&amp;gt;/usr/local/lib&amp;lt;/tt&amp;gt;), and it should be seen by opensim (&amp;lt;tt&amp;gt;ode.net.dll&amp;lt;/tt&amp;gt;)&lt;br /&gt;
&lt;br /&gt;
===Running===&lt;br /&gt;
Recent versions of OpenSim come without an &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file. Copy the &amp;lt;tt&amp;gt;OpenSim.ini.example&amp;lt;/tt&amp;gt; file to &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; before making any changes.&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
* To invoke ODE, add the option:&lt;br /&gt;
 -physics=OpenDynamicsEngine&lt;br /&gt;
to the &amp;lt;tt&amp;gt;mono OpenSim.exe&amp;lt;/tt&amp;gt; line&lt;br /&gt;
&lt;br /&gt;
or add &amp;lt;code&amp;gt;  physics = OpenDynamicsEngine &amp;lt;/code&amp;gt; to the [Startup] section of &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt;.  Same deal for other physics engines, when available.&lt;br /&gt;
&lt;br /&gt;
On mono 1.2.6, some distributions may see&lt;br /&gt;
 Unhandled Exception: System.NotSupportedException: CodePage 1252 not supported&lt;br /&gt;
on startup when using mysql.  This can be resolved by installing the package libmono-i18n2.0-cil (see http://bugs.mysql.com/bug.php?id=33938).&lt;br /&gt;
&lt;br /&gt;
=== Additional Items ===&lt;br /&gt;
&lt;br /&gt;
* [[GC_NO_EXPLICIT|GC NO EXPLICIT]] - Enable Large Heap in Mono, this has been known to help performance and stability&lt;br /&gt;
&lt;br /&gt;
[[Category:Users]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:51:29Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* RestInventoryServices */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;br /&gt;
&lt;br /&gt;
The process for adding a new service is straightforward. The file &amp;lt;tt&amp;gt;RestTestServices.cs&amp;lt;/tt&amp;gt; serves as an example1 of what a new services class must minimally include. Key points to note are:&lt;br /&gt;
&lt;br /&gt;
# Each service class should have an associated value for &amp;lt;tt&amp;gt;qPrefix&amp;lt;/tt&amp;gt;. This should be unique for each service, as it represents the relative extension of the URI that will be matched by this service. The value supplied here may be absolute, but this is discouraged. The constructor will automatically update a relative value to reflect the absolute prefix set globally during initialization.&lt;br /&gt;
# In the case of test services the constructor loads a set of classes from a sub-directory, each of which represents a specific service implementation. For example, these may be method-related, or based upon other values contained in the supplied URI.&lt;br /&gt;
# The services constructor must register itself with the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;. It provides three values at registration time: a reference to the service method, the URI prefix that this service will match, and a reference to an &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; allocation method that will return an appropriately sub-classed instance of the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; class.&lt;br /&gt;
# Implementation of the service and allocation methods described above must be provided.&lt;br /&gt;
&lt;br /&gt;
Other methods definitions are simply part of the overall infrastructure and would be unique to a given service implementation.&lt;br /&gt;
&lt;br /&gt;
''Note that a given services class may implement zero or more services, according to its intended function. A class providing shared functionality to other services may be loaded but not register any actual handling methods. Similarly, a single services class could register multiple handling methods.''&lt;br /&gt;
&lt;br /&gt;
== REST Implementation Classes ==&lt;br /&gt;
&lt;br /&gt;
This section provides additional documentation of the state and services provided by &amp;lt;tt&amp;gt;Rest.cs&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt; files.&lt;br /&gt;
&lt;br /&gt;
=== Rest.cs ===&lt;br /&gt;
&lt;br /&gt;
The eponymous class provides a collection of ''request independent'' services and state definitions. Any functions directly dependent upon the HTTP request and response elements are provided in &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== State ====&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Log&amp;lt;/tt&amp;gt; declaration provides local access to the &amp;lt;tt&amp;gt;log4net&amp;lt;/tt&amp;gt; facility. Though apparently complex it simply resolves to a static, read-only reference that can be used to pass messages to the logging facility.&lt;br /&gt;
&lt;br /&gt;
The value of &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; reflects whether or not debug messages have been enabled in the OpenSim log. If they have, then &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; will be enabled, if not, then they will not. Being a static declaration it is anticipated that the JIT compiler will be able to make efficient code generation assumptions. This is only of real significance where some substantial operation is performed solely in support of debugging.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Plugin&amp;lt;/tt&amp;gt; reference is set by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. It eliminates the need for a services class to have direct awareness of how it was activated. For example, this reference is used to locate the &amp;lt;tt&amp;gt;AddPathHandler&amp;lt;/tt&amp;gt; method  needed to register its interface.&lt;br /&gt;
&lt;br /&gt;
The main reference is set by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. Its value is a reference to the simulator's base class. It is provided to the plug-in interface and is stored for that reason. It is not currently used except by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate the communications manager during initialization.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Comms&amp;lt;/tt&amp;gt; provides a globally accessible reference to the simulator's communications manager. It is initialized by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization and is currently only used by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate other, commonly needed, simulator services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;InventoryServices&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;UserServices&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;AssetServices&amp;lt;/tt&amp;gt; are references to the corresponding simulator service interfaces. This list may grow as common service requirements expand.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Prefix&amp;lt;/tt&amp;gt; is the common URI prefix associated with all handlers within a given assembly. In the case of inventory services it is obtained from the global REST configuration. It is currently /admin. This is a configurable attribute. Typical this should be set to whatever is considered to be the standard prefix for REST services in a given URI, it will be combined with scheme and authority information to construct a valid URL.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Config&amp;lt;/tt&amp;gt; is a saved reference to the configuration file used by this assembly. The configuration partition is identified by the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; string supplied by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; implementation. This is currently only used by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;, but it could be used by a service implementation to access attributes unique to the service.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;GodKey&amp;lt;/tt&amp;gt; is a string obtained from the configuration file which contains the password for the God user. This user has unfettered access to all administrative functions. This is a temporary mechanism and will eventually be replaced by something more secure. This is a configurable attribute.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Authenticate&amp;lt;/tt&amp;gt; indicates whether or not user authentication is required by this handler. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Secure&amp;lt;/tt&amp;gt; indicates whether or not the HTTP session should be secured. Secure sessions are currently not available to OpenSim. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;ExtendedEscape&amp;lt;/tt&amp;gt; controls whether or not the URI is processed for parsing extensions such as “+” in place of spaces. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt; controls whether or not the content of an incoming asset should be dumped to the trace file after decoding has completed. This is only intended to be used when there is some indication of a problem with the decoding process. It may produce a significant amount of trace output depending upon the quantity of asset data being uploaded. This is configurable and is normally false.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Fill&amp;lt;/tt&amp;gt; controls whether or not the server will automatically generate intermediate folder names when handling a POST request; it is not currently considered appropriate for PUT. This is not presently implemented.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;FlushEnabled&amp;lt;/tt&amp;gt; indicates that the server will completely flush an inbound data stream before responding. This accommodates clients that can not handle the case where a socket error is generated as a result of an early termination of the inbound data stream (due to an authentication failure for example). This mechanism is vulnerable to DOS attacks and can be selectively enabled/disabled.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Realm&amp;lt;/tt&amp;gt; is a string that may be used to distinguish the authentication realm associated with the handler, in place of the URI prefix. This corresponds directly to the realm token included in the WWW-Authenticate response header. This is a configurable option, and is set to 'OpenSim REST' by default. Clients may use this value to determine if additional authentication is necessary, or to select appropriate cached credentials.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpLineSize&amp;lt;/tt&amp;gt; indicates the line length to use for any data dumps (e.g. &amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt;) during runtime. The default is 132. This is a configurable option.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;statusHead&amp;lt;/tt&amp;gt; contains the standard HTML header used for reporting request status. Similarly, &amp;lt;tt&amp;gt;statusTail&amp;lt;/tt&amp;gt; is used to provide a standard suffix. These are both used by the standard status reporting mechanisms.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;HttpStatusDesc&amp;lt;/tt&amp;gt; is an array which, when indexed by an appropriate HTTP status code, will return a corresponding status description.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;CreationDate&amp;lt;/tt&amp;gt; (property) provides a single consistent reference for creation data value needed when introducing new items into the inventory.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;MsgId&amp;lt;/tt&amp;gt; (property) provides a consistent message prefix for log messages generated by the handler. Although static, the value is thread specific, so it is actually unique per request.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;RequestId&amp;lt;/tt&amp;gt; (property) provides a unique, monotonically incrementing request counter for processed requests.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Encoding&amp;lt;/tt&amp;gt; provides a standard encoding reference (UTF8) for all data handled by the handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Version&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;Name&amp;lt;/tt&amp;gt; are intended to uniquely identify the REST implementation represented by this particular class. Version information should be updated if any significant changes to the REST interface are implemented. This is not currently exploited, but should be. We should have an extended header that indicates the REST version that the client is expecting, and the Match process should be sensitive to this. In this way we can provide concurrent support for multiple REST versions.&lt;br /&gt;
&lt;br /&gt;
The extensive list of constant values are all held to be self-explanatory and should be used wheresoever the value they represent is required in a service implementation. This ensures consistency between the REST implementation and the REST service implementations.&lt;br /&gt;
&lt;br /&gt;
==== Functions ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;StringToBase64&amp;lt;/tt&amp;gt; provides a standard Base64 encoding mechanism for service implementations.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Base64ToString&amp;lt;/tt&amp;gt; provides a standard Base64 decoding mechanism for service implementations.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Hex2Int&amp;lt;/tt&amp;gt; provides a standard mechanism for converting a hexadecimal string of arbitrary length into an integer.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Int2hex8&amp;lt;/tt&amp;gt; converts an integer into an 8 character hexadecimal number. This is not currently used, and as such should not be trusted.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;NonceGenerator&amp;lt;/tt&amp;gt; is a simple nonce producer that ensures uniqueness by simply converting a newly generated UUID into a Base64 string. This function is called each time the user is called upon to authenticate, which is not necessarily that often, provided the client caches credentials based upon realm.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Dump&amp;lt;/tt&amp;gt; provides a general purpose facility for generating an interpreted hexadecimal data dump to the log file. It is currently used by the DumpAsset debug facility. But it may be used by anybody requiring such data dumping services.&lt;br /&gt;
&lt;br /&gt;
=== RequestException ===&lt;br /&gt;
&lt;br /&gt;
This class provides an extended exception that can be distinguished from regular, system generated, exceptions. A &amp;lt;tt&amp;gt;RequestException&amp;lt;/tt&amp;gt; does not indicate a programming failure, rather it indicates that the received request could not be validly processed, for example, the URI was invalid. This exception should only be used in those cases where request processing is to be immediately terminated in conjunction with normal response processing. Principally it allows the handler to differentiate between a failure in processing, which should be logged, and a normal response to an invalid request, which should not.&lt;br /&gt;
&lt;br /&gt;
=== RequestData.cs ===&lt;br /&gt;
&lt;br /&gt;
This file, and its eponymous class provides consistent support for request specific REST processing. When the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; has successfully matched a handler to a request, the registered allocate method for that service interface is called to allocate an instance of this class either directly, or  as a super class of some service specific extension. This description deals only with the base implementation.&lt;br /&gt;
&lt;br /&gt;
With a single instance of a service class per handler, it is necessary to encapsulate request/response specific data in this way. Those functions that operate over that data are included here for convenience and represent part of the previously mentioned REST implementation encapsulation.&lt;br /&gt;
&lt;br /&gt;
==== Members ====&lt;br /&gt;
&lt;br /&gt;
When an instance of this class is created, the constructor always does the following:&lt;br /&gt;
&lt;br /&gt;
# The parameters are not validated. Their validity is considered to be a precondition and as such the natural exception mechanism is an efficient and effective way to deal with invalid argument values.&lt;br /&gt;
# The supplied request and response object references are cached, as is the supplied request prefix.&lt;br /&gt;
# The effective encoding is obtained from the supplied request if possible, or the Rest default (UTF8) is applied.&lt;br /&gt;
# A lower case copy of the request method is stored.&lt;br /&gt;
# &amp;lt;tt&amp;gt;InitUrl&amp;lt;/tt&amp;gt; is called to decompose the supplied URI into its basic components: query, path, host name, and  port.&lt;br /&gt;
# &amp;lt;tt&amp;gt;InitParameters&amp;lt;/tt&amp;gt; is called to create an array of strings, each of which represents a separated portion of whatever URI remains after the handler's selection prefix is removed. This list may be empty.&lt;br /&gt;
&lt;br /&gt;
In the interests of laziness, constructor processing is kept to a minimum.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;IsAuthenticated&amp;lt;/tt&amp;gt; property checks to see if the user is currently authenticated, and if not, then invokes that authentication mechanism. This allows a service request handler so simply test this boolean and reject the request if the result is false. This is an example of a failure that should not normally be logged, as the client is expected to respond to the challenge with an appropriate set of credentials.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;PathNodes&amp;lt;/tt&amp;gt; property is an array that contains a normalized list of elements in the absolute path provided in the URI. It does not differentiate the elements.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Parameters&amp;lt;/tt&amp;gt; property is an array that contains only those URI path elements that are not a part of the service selection prefix (i.e. &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt;). This simplifies service processing by providing a prefix-independent base for request parameter indeces.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Complete&amp;lt;/tt&amp;gt; allows a service provider to indicate the manner in which a request has completed. Called with no arguments, this corresponds to a status code of 200 indicating a normal completion. In many cases the service provider must necessarily indicate a more specific code. The message associated with this call may be arbitrarily complex, it is used, as-is, as the message body in the response.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Redirect&amp;lt;/tt&amp;gt; allows a service provider to indicate that the requester should be redirected to an alternative URL. Redirection may be permanent or temporary as indicated by the boolean argument.&lt;br /&gt;
&lt;br /&gt;
Variations on &amp;lt;tt&amp;gt;Fail&amp;lt;/tt&amp;gt; allow a service to abandon request processing. This call constructs an appropriate HTTP failure response, including any specified message body, generates the response, adds request information to an instance of &amp;lt;tt&amp;gt;RestException&amp;lt;/tt&amp;gt; and finally throws the exception. It is important that a service provider allow &amp;lt;tt&amp;gt;RestException&amp;lt;/tt&amp;gt; events to pass through transparently, (i.e. re-throw any that are inadvertently trapped).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Reject&amp;lt;/tt&amp;gt; encapsulates whatever processing is appropriate for requests that attempted processing that is not implemented.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Respond&amp;lt;/tt&amp;gt; allows a service provider to generate a response and complete processing with respect to the current HTTP request and response. This call is mandatory for any request that is considered to have been processed successfully.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;AddHeader&amp;lt;/tt&amp;gt; allows a service provider to add a header to the set of response headers that will be included  when the response is finally generated. The Rest constants should be used when specifying the header name. The header value is treated as an arbitrary string.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;RemoveHeader&amp;lt;/tt&amp;gt; allows a service provider to remove a header that was previously added to the response header set.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpHeaders&amp;lt;/tt&amp;gt; causes a list of the currently effective headers to be sent to the log. This is a DEBUG option.&lt;br /&gt;
&lt;br /&gt;
== RestInventoryServices ==&lt;br /&gt;
This file, and the classes it contains, provide a monolithic implementation of all of the services provided in support of inventory processing. If required, authentication is established before any processing of inventory data. The following abnormal completion codes may be returned:&lt;br /&gt;
&lt;br /&gt;
* 301 indicating that a permanently applicable alternative URI for a specified resource has been provided.&lt;br /&gt;
* 400 indicating a bad request. Information about the nature of the request error is included in the status information returned to the client. Currently this is textual, but when a proper schema document for the interface is established, a more quantitative status will be returned.&lt;br /&gt;
* 401 indicating that the client must authenticate.&lt;br /&gt;
* 409 indicating that an ambiguous or conflicting request was received.&lt;br /&gt;
&lt;br /&gt;
=== Inventory Resource Identification ===&lt;br /&gt;
&lt;br /&gt;
An avatar's inventory is a catalog of the assets 'owned' by the avatar; the inventory contains only of meta-data and depends upon the asset data base for whatever actual data represents the perceived content. References to inventory in this document normally refer to the meta-data rather than the content. An inventory consists of two types of element: ''folders'' and ''items''. In both cases, a given element is uniquely identified by an assigned UUID. An associated name is also provided for human convenience, but such names are not required to be unique and are insufficient to ensure an exact identification. The URI used in inventory related requests allows either UUID or name to specified for each element in a resource identification path, ''if any ambiguity arises then the request will be failed''.&lt;br /&gt;
&lt;br /&gt;
The avatar's inventory can contain a private catalog, and one or more shared, or public, catalogs. Currently only the private catalog is processed. When support for the shared catalogs is introduced it will do so by adding by prefixing any path as follows:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
/admin/inventory/shared/[&amp;lt;libname&amp;gt;]/&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This allows all global inventory, or a specific library to be referenced.&lt;br /&gt;
For all requests, specifying an avatar name implies the private inventory.&lt;br /&gt;
In all cases, if additional path information is provided, then the root directory name may be inferred (but accepted if specified explicitly). So&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
/admin/inventory/Alan Webb/My Inventory/Clothing&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
and&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
/admin/inventory/Alan Webb/Clothing&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
are semantically equivalent. This is a convenient and harmless special case. Where no additional path information is provided, as in&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
then the root directory may still be inferred for GET and POST, but can not be allowed for PUT. PUT requires the URI to identify the element that is being updated, so inference in this case could be extremely damaging. Explicit specification of the root inventory name is therefore required for all PUT requests. Given that this is an interface normally used only by programmed clients, the additional verbosity is not expected to be an issue. If this proves to be contentious, then the only viable approach would be to drop the inference altogether.&lt;br /&gt;
&lt;br /&gt;
=== Supported Services ===&lt;br /&gt;
&lt;br /&gt;
==== GET ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;GET&amp;lt;/tt&amp;gt; allows the client to retrieve all, or some sub-tree of, the inventory associated with a specified avatar's inventory. Inventory information is returned in an XML payload. This request is guaranteed not to affect the state of the avatar's inventory. Possible normal completions are:&lt;br /&gt;
&lt;br /&gt;
* 200 indicating normal completion of the request. The payload will contain an XML representation of the avatar's inventory.&lt;br /&gt;
&lt;br /&gt;
==== PUT ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;PUT&amp;lt;/tt&amp;gt; allows a resource, explicitly nominated in the URI, to be created or replaced. I.e. the URI identifies an instance rather than a context. Possible normal completions are&lt;br /&gt;
&lt;br /&gt;
* 200 if the nominated resource was successfully updated&lt;br /&gt;
* 201 if the nominated resource was successfully created.&lt;br /&gt;
* 204 if no content change (but the resource was recognized and valid)&lt;br /&gt;
&lt;br /&gt;
==== POST ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;POST&amp;lt;/tt&amp;gt; allows a new resource to be created in the context identified by the URI. It follows from this that the resource identified by a POST request should always be a folder. Normal completions are:&lt;br /&gt;
&lt;br /&gt;
* 200 if some portion of the context was modified.&lt;br /&gt;
* 201 if the new data was entirely new.&lt;br /&gt;
&lt;br /&gt;
==== DELETE ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DELETE&amp;lt;/tt&amp;gt; allows a named resource to be deleted. If the resource is a folder, then the entire sub-tree will be removed. Normal completion codes are:&lt;br /&gt;
&lt;br /&gt;
* 200 if the specified resource was deleted.&lt;br /&gt;
&lt;br /&gt;
Both PUT and POST allow any assets upon which the inventory catalog depends, to be included in-line with the XML catalog data.&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:42:53Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Functions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;br /&gt;
&lt;br /&gt;
The process for adding a new service is straightforward. The file &amp;lt;tt&amp;gt;RestTestServices.cs&amp;lt;/tt&amp;gt; serves as an example1 of what a new services class must minimally include. Key points to note are:&lt;br /&gt;
&lt;br /&gt;
# Each service class should have an associated value for &amp;lt;tt&amp;gt;qPrefix&amp;lt;/tt&amp;gt;. This should be unique for each service, as it represents the relative extension of the URI that will be matched by this service. The value supplied here may be absolute, but this is discouraged. The constructor will automatically update a relative value to reflect the absolute prefix set globally during initialization.&lt;br /&gt;
# In the case of test services the constructor loads a set of classes from a sub-directory, each of which represents a specific service implementation. For example, these may be method-related, or based upon other values contained in the supplied URI.&lt;br /&gt;
# The services constructor must register itself with the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;. It provides three values at registration time: a reference to the service method, the URI prefix that this service will match, and a reference to an &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; allocation method that will return an appropriately sub-classed instance of the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; class.&lt;br /&gt;
# Implementation of the service and allocation methods described above must be provided.&lt;br /&gt;
&lt;br /&gt;
Other methods definitions are simply part of the overall infrastructure and would be unique to a given service implementation.&lt;br /&gt;
&lt;br /&gt;
''Note that a given services class may implement zero or more services, according to its intended function. A class providing shared functionality to other services may be loaded but not register any actual handling methods. Similarly, a single services class could register multiple handling methods.''&lt;br /&gt;
&lt;br /&gt;
== REST Implementation Classes ==&lt;br /&gt;
&lt;br /&gt;
This section provides additional documentation of the state and services provided by &amp;lt;tt&amp;gt;Rest.cs&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt; files.&lt;br /&gt;
&lt;br /&gt;
=== Rest.cs ===&lt;br /&gt;
&lt;br /&gt;
The eponymous class provides a collection of ''request independent'' services and state definitions. Any functions directly dependent upon the HTTP request and response elements are provided in &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== State ====&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Log&amp;lt;/tt&amp;gt; declaration provides local access to the &amp;lt;tt&amp;gt;log4net&amp;lt;/tt&amp;gt; facility. Though apparently complex it simply resolves to a static, read-only reference that can be used to pass messages to the logging facility.&lt;br /&gt;
&lt;br /&gt;
The value of &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; reflects whether or not debug messages have been enabled in the OpenSim log. If they have, then &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; will be enabled, if not, then they will not. Being a static declaration it is anticipated that the JIT compiler will be able to make efficient code generation assumptions. This is only of real significance where some substantial operation is performed solely in support of debugging.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Plugin&amp;lt;/tt&amp;gt; reference is set by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. It eliminates the need for a services class to have direct awareness of how it was activated. For example, this reference is used to locate the &amp;lt;tt&amp;gt;AddPathHandler&amp;lt;/tt&amp;gt; method  needed to register its interface.&lt;br /&gt;
&lt;br /&gt;
The main reference is set by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. Its value is a reference to the simulator's base class. It is provided to the plug-in interface and is stored for that reason. It is not currently used except by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate the communications manager during initialization.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Comms&amp;lt;/tt&amp;gt; provides a globally accessible reference to the simulator's communications manager. It is initialized by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization and is currently only used by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate other, commonly needed, simulator services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;InventoryServices&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;UserServices&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;AssetServices&amp;lt;/tt&amp;gt; are references to the corresponding simulator service interfaces. This list may grow as common service requirements expand.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Prefix&amp;lt;/tt&amp;gt; is the common URI prefix associated with all handlers within a given assembly. In the case of inventory services it is obtained from the global REST configuration. It is currently /admin. This is a configurable attribute. Typical this should be set to whatever is considered to be the standard prefix for REST services in a given URI, it will be combined with scheme and authority information to construct a valid URL.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Config&amp;lt;/tt&amp;gt; is a saved reference to the configuration file used by this assembly. The configuration partition is identified by the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; string supplied by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; implementation. This is currently only used by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;, but it could be used by a service implementation to access attributes unique to the service.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;GodKey&amp;lt;/tt&amp;gt; is a string obtained from the configuration file which contains the password for the God user. This user has unfettered access to all administrative functions. This is a temporary mechanism and will eventually be replaced by something more secure. This is a configurable attribute.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Authenticate&amp;lt;/tt&amp;gt; indicates whether or not user authentication is required by this handler. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Secure&amp;lt;/tt&amp;gt; indicates whether or not the HTTP session should be secured. Secure sessions are currently not available to OpenSim. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;ExtendedEscape&amp;lt;/tt&amp;gt; controls whether or not the URI is processed for parsing extensions such as “+” in place of spaces. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt; controls whether or not the content of an incoming asset should be dumped to the trace file after decoding has completed. This is only intended to be used when there is some indication of a problem with the decoding process. It may produce a significant amount of trace output depending upon the quantity of asset data being uploaded. This is configurable and is normally false.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Fill&amp;lt;/tt&amp;gt; controls whether or not the server will automatically generate intermediate folder names when handling a POST request; it is not currently considered appropriate for PUT. This is not presently implemented.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;FlushEnabled&amp;lt;/tt&amp;gt; indicates that the server will completely flush an inbound data stream before responding. This accommodates clients that can not handle the case where a socket error is generated as a result of an early termination of the inbound data stream (due to an authentication failure for example). This mechanism is vulnerable to DOS attacks and can be selectively enabled/disabled.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Realm&amp;lt;/tt&amp;gt; is a string that may be used to distinguish the authentication realm associated with the handler, in place of the URI prefix. This corresponds directly to the realm token included in the WWW-Authenticate response header. This is a configurable option, and is set to 'OpenSim REST' by default. Clients may use this value to determine if additional authentication is necessary, or to select appropriate cached credentials.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpLineSize&amp;lt;/tt&amp;gt; indicates the line length to use for any data dumps (e.g. &amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt;) during runtime. The default is 132. This is a configurable option.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;statusHead&amp;lt;/tt&amp;gt; contains the standard HTML header used for reporting request status. Similarly, &amp;lt;tt&amp;gt;statusTail&amp;lt;/tt&amp;gt; is used to provide a standard suffix. These are both used by the standard status reporting mechanisms.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;HttpStatusDesc&amp;lt;/tt&amp;gt; is an array which, when indexed by an appropriate HTTP status code, will return a corresponding status description.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;CreationDate&amp;lt;/tt&amp;gt; (property) provides a single consistent reference for creation data value needed when introducing new items into the inventory.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;MsgId&amp;lt;/tt&amp;gt; (property) provides a consistent message prefix for log messages generated by the handler. Although static, the value is thread specific, so it is actually unique per request.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;RequestId&amp;lt;/tt&amp;gt; (property) provides a unique, monotonically incrementing request counter for processed requests.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Encoding&amp;lt;/tt&amp;gt; provides a standard encoding reference (UTF8) for all data handled by the handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Version&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;Name&amp;lt;/tt&amp;gt; are intended to uniquely identify the REST implementation represented by this particular class. Version information should be updated if any significant changes to the REST interface are implemented. This is not currently exploited, but should be. We should have an extended header that indicates the REST version that the client is expecting, and the Match process should be sensitive to this. In this way we can provide concurrent support for multiple REST versions.&lt;br /&gt;
&lt;br /&gt;
The extensive list of constant values are all held to be self-explanatory and should be used wheresoever the value they represent is required in a service implementation. This ensures consistency between the REST implementation and the REST service implementations.&lt;br /&gt;
&lt;br /&gt;
==== Functions ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;StringToBase64&amp;lt;/tt&amp;gt; provides a standard Base64 encoding mechanism for service implementations.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Base64ToString&amp;lt;/tt&amp;gt; provides a standard Base64 decoding mechanism for service implementations.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Hex2Int&amp;lt;/tt&amp;gt; provides a standard mechanism for converting a hexadecimal string of arbitrary length into an integer.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Int2hex8&amp;lt;/tt&amp;gt; converts an integer into an 8 character hexadecimal number. This is not currently used, and as such should not be trusted.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;NonceGenerator&amp;lt;/tt&amp;gt; is a simple nonce producer that ensures uniqueness by simply converting a newly generated UUID into a Base64 string. This function is called each time the user is called upon to authenticate, which is not necessarily that often, provided the client caches credentials based upon realm.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Dump&amp;lt;/tt&amp;gt; provides a general purpose facility for generating an interpreted hexadecimal data dump to the log file. It is currently used by the DumpAsset debug facility. But it may be used by anybody requiring such data dumping services.&lt;br /&gt;
&lt;br /&gt;
=== RequestException ===&lt;br /&gt;
&lt;br /&gt;
This class provides an extended exception that can be distinguished from regular, system generated, exceptions. A &amp;lt;tt&amp;gt;RequestException&amp;lt;/tt&amp;gt; does not indicate a programming failure, rather it indicates that the received request could not be validly processed, for example, the URI was invalid. This exception should only be used in those cases where request processing is to be immediately terminated in conjunction with normal response processing. Principally it allows the handler to differentiate between a failure in processing, which should be logged, and a normal response to an invalid request, which should not.&lt;br /&gt;
&lt;br /&gt;
=== RequestData.cs ===&lt;br /&gt;
&lt;br /&gt;
This file, and its eponymous class provides consistent support for request specific REST processing. When the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; has successfully matched a handler to a request, the registered allocate method for that service interface is called to allocate an instance of this class either directly, or  as a super class of some service specific extension. This description deals only with the base implementation.&lt;br /&gt;
&lt;br /&gt;
With a single instance of a service class per handler, it is necessary to encapsulate request/response specific data in this way. Those functions that operate over that data are included here for convenience and represent part of the previously mentioned REST implementation encapsulation.&lt;br /&gt;
&lt;br /&gt;
==== Members ====&lt;br /&gt;
&lt;br /&gt;
When an instance of this class is created, the constructor always does the following:&lt;br /&gt;
&lt;br /&gt;
# The parameters are not validated. Their validity is considered to be a precondition and as such the natural exception mechanism is an efficient and effective way to deal with invalid argument values.&lt;br /&gt;
# The supplied request and response object references are cached, as is the supplied request prefix.&lt;br /&gt;
# The effective encoding is obtained from the supplied request if possible, or the Rest default (UTF8) is applied.&lt;br /&gt;
# A lower case copy of the request method is stored.&lt;br /&gt;
# &amp;lt;tt&amp;gt;InitUrl&amp;lt;/tt&amp;gt; is called to decompose the supplied URI into its basic components: query, path, host name, and  port.&lt;br /&gt;
# &amp;lt;tt&amp;gt;InitParameters&amp;lt;/tt&amp;gt; is called to create an array of strings, each of which represents a separated portion of whatever URI remains after the handler's selection prefix is removed. This list may be empty.&lt;br /&gt;
&lt;br /&gt;
In the interests of laziness, constructor processing is kept to a minimum.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;IsAuthenticated&amp;lt;/tt&amp;gt; property checks to see if the user is currently authenticated, and if not, then invokes that authentication mechanism. This allows a service request handler so simply test this boolean and reject the request if the result is false. This is an example of a failure that should not normally be logged, as the client is expected to respond to the challenge with an appropriate set of credentials.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;PathNodes&amp;lt;/tt&amp;gt; property is an array that contains a normalized list of elements in the absolute path provided in the URI. It does not differentiate the elements.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Parameters&amp;lt;/tt&amp;gt; property is an array that contains only those URI path elements that are not a part of the service selection prefix (i.e. &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt;). This simplifies service processing by providing a prefix-independent base for request parameter indeces.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Complete&amp;lt;/tt&amp;gt; allows a service provider to indicate the manner in which a request has completed. Called with no arguments, this corresponds to a status code of 200 indicating a normal completion. In many cases the service provider must necessarily indicate a more specific code. The message associated with this call may be arbitrarily complex, it is used, as-is, as the message body in the response.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Redirect&amp;lt;/tt&amp;gt; allows a service provider to indicate that the requester should be redirected to an alternative URL. Redirection may be permanent or temporary as indicated by the boolean argument.&lt;br /&gt;
&lt;br /&gt;
Variations on &amp;lt;tt&amp;gt;Fail&amp;lt;/tt&amp;gt; allow a service to abandon request processing. This call constructs an appropriate HTTP failure response, including any specified message body, generates the response, adds request information to an instance of &amp;lt;tt&amp;gt;RestException&amp;lt;/tt&amp;gt; and finally throws the exception. It is important that a service provider allow &amp;lt;tt&amp;gt;RestException&amp;lt;/tt&amp;gt; events to pass through transparently, (i.e. re-throw any that are inadvertently trapped).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Reject&amp;lt;/tt&amp;gt; encapsulates whatever processing is appropriate for requests that attempted processing that is not implemented.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Respond&amp;lt;/tt&amp;gt; allows a service provider to generate a response and complete processing with respect to the current HTTP request and response. This call is mandatory for any request that is considered to have been processed successfully.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;AddHeader&amp;lt;/tt&amp;gt; allows a service provider to add a header to the set of response headers that will be included  when the response is finally generated. The Rest constants should be used when specifying the header name. The header value is treated as an arbitrary string.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;RemoveHeader&amp;lt;/tt&amp;gt; allows a service provider to remove a header that was previously added to the response header set.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpHeaders&amp;lt;/tt&amp;gt; causes a list of the currently effective headers to be sent to the log. This is a DEBUG option.&lt;br /&gt;
&lt;br /&gt;
== RestInventoryServices ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:31:40Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* REST Implementation Classes */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;br /&gt;
&lt;br /&gt;
The process for adding a new service is straightforward. The file &amp;lt;tt&amp;gt;RestTestServices.cs&amp;lt;/tt&amp;gt; serves as an example1 of what a new services class must minimally include. Key points to note are:&lt;br /&gt;
&lt;br /&gt;
# Each service class should have an associated value for &amp;lt;tt&amp;gt;qPrefix&amp;lt;/tt&amp;gt;. This should be unique for each service, as it represents the relative extension of the URI that will be matched by this service. The value supplied here may be absolute, but this is discouraged. The constructor will automatically update a relative value to reflect the absolute prefix set globally during initialization.&lt;br /&gt;
# In the case of test services the constructor loads a set of classes from a sub-directory, each of which represents a specific service implementation. For example, these may be method-related, or based upon other values contained in the supplied URI.&lt;br /&gt;
# The services constructor must register itself with the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;. It provides three values at registration time: a reference to the service method, the URI prefix that this service will match, and a reference to an &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; allocation method that will return an appropriately sub-classed instance of the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; class.&lt;br /&gt;
# Implementation of the service and allocation methods described above must be provided.&lt;br /&gt;
&lt;br /&gt;
Other methods definitions are simply part of the overall infrastructure and would be unique to a given service implementation.&lt;br /&gt;
&lt;br /&gt;
''Note that a given services class may implement zero or more services, according to its intended function. A class providing shared functionality to other services may be loaded but not register any actual handling methods. Similarly, a single services class could register multiple handling methods.''&lt;br /&gt;
&lt;br /&gt;
== REST Implementation Classes ==&lt;br /&gt;
&lt;br /&gt;
This section provides additional documentation of the state and services provided by &amp;lt;tt&amp;gt;Rest.cs&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt; files.&lt;br /&gt;
&lt;br /&gt;
=== Rest.cs ===&lt;br /&gt;
&lt;br /&gt;
The eponymous class provides a collection of ''request independent'' services and state definitions. Any functions directly dependent upon the HTTP request and response elements are provided in &amp;lt;tt&amp;gt;RequestData.cs&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== State ====&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Log&amp;lt;/tt&amp;gt; declaration provides local access to the &amp;lt;tt&amp;gt;log4net&amp;lt;/tt&amp;gt; facility. Though apparently complex it simply resolves to a static, read-only reference that can be used to pass messages to the logging facility.&lt;br /&gt;
&lt;br /&gt;
The value of &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; reflects whether or not debug messages have been enabled in the OpenSim log. If they have, then &amp;lt;tt&amp;gt;DEBUG&amp;lt;/tt&amp;gt; will be enabled, if not, then they will not. Being a static declaration it is anticipated that the JIT compiler will be able to make efficient code generation assumptions. This is only of real significance where some substantial operation is performed solely in support of debugging.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;Plugin&amp;lt;/tt&amp;gt; reference is set by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. It eliminates the need for a services class to have direct awareness of how it was activated. For example, this reference is used to locate the &amp;lt;tt&amp;gt;AddPathHandler&amp;lt;/tt&amp;gt; method  needed to register its interface.&lt;br /&gt;
&lt;br /&gt;
The main reference is set by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization. Its value is a reference to the simulator's base class. It is provided to the plug-in interface and is stored for that reason. It is not currently used except by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate the communications manager during initialization.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Comms&amp;lt;/tt&amp;gt; provides a globally accessible reference to the simulator's communications manager. It is initialized by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; during initialization and is currently only used by &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; to locate other, commonly needed, simulator services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;InventoryServices&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;UserServices&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;AssetServices&amp;lt;/tt&amp;gt; are references to the corresponding simulator service interfaces. This list may grow as common service requirements expand.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Prefix&amp;lt;/tt&amp;gt; is the common URI prefix associated with all handlers within a given assembly. In the case of inventory services it is obtained from the global REST configuration. It is currently /admin. This is a configurable attribute. Typical this should be set to whatever is considered to be the standard prefix for REST services in a given URI, it will be combined with scheme and authority information to construct a valid URL.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Config&amp;lt;/tt&amp;gt; is a saved reference to the configuration file used by this assembly. The configuration partition is identified by the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; string supplied by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; implementation. This is currently only used by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;, but it could be used by a service implementation to access attributes unique to the service.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;GodKey&amp;lt;/tt&amp;gt; is a string obtained from the configuration file which contains the password for the God user. This user has unfettered access to all administrative functions. This is a temporary mechanism and will eventually be replaced by something more secure. This is a configurable attribute.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Authenticate&amp;lt;/tt&amp;gt; indicates whether or not user authentication is required by this handler. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Secure&amp;lt;/tt&amp;gt; indicates whether or not the HTTP session should be secured. Secure sessions are currently not available to OpenSim. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;ExtendedEscape&amp;lt;/tt&amp;gt; controls whether or not the URI is processed for parsing extensions such as “+” in place of spaces. This is a configurable attribute, true by default.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt; controls whether or not the content of an incoming asset should be dumped to the trace file after decoding has completed. This is only intended to be used when there is some indication of a problem with the decoding process. It may produce a significant amount of trace output depending upon the quantity of asset data being uploaded. This is configurable and is normally false.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Fill&amp;lt;/tt&amp;gt; controls whether or not the server will automatically generate intermediate folder names when handling a POST request; it is not currently considered appropriate for PUT. This is not presently implemented.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;FlushEnabled&amp;lt;/tt&amp;gt; indicates that the server will completely flush an inbound data stream before responding. This accommodates clients that can not handle the case where a socket error is generated as a result of an early termination of the inbound data stream (due to an authentication failure for example). This mechanism is vulnerable to DOS attacks and can be selectively enabled/disabled.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Realm&amp;lt;/tt&amp;gt; is a string that may be used to distinguish the authentication realm associated with the handler, in place of the URI prefix. This corresponds directly to the realm token included in the WWW-Authenticate response header. This is a configurable option, and is set to 'OpenSim REST' by default. Clients may use this value to determine if additional authentication is necessary, or to select appropriate cached credentials.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;DumpLineSize&amp;lt;/tt&amp;gt; indicates the line length to use for any data dumps (e.g. &amp;lt;tt&amp;gt;DumpAsset&amp;lt;/tt&amp;gt;) during runtime. The default is 132. This is a configurable option.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;statusHead&amp;lt;/tt&amp;gt; contains the standard HTML header used for reporting request status. Similarly, &amp;lt;tt&amp;gt;statusTail&amp;lt;/tt&amp;gt; is used to provide a standard suffix. These are both used by the standard status reporting mechanisms.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;HttpStatusDesc&amp;lt;/tt&amp;gt; is an array which, when indexed by an appropriate HTTP status code, will return a corresponding status description.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;CreationDate&amp;lt;/tt&amp;gt; (property) provides a single consistent reference for creation data value needed when introducing new items into the inventory.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;MsgId&amp;lt;/tt&amp;gt; (property) provides a consistent message prefix for log messages generated by the handler. Although static, the value is thread specific, so it is actually unique per request.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;RequestId&amp;lt;/tt&amp;gt; (property) provides a unique, monotonically incrementing request counter for processed requests.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Encoding&amp;lt;/tt&amp;gt; provides a standard encoding reference (UTF8) for all data handled by the handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;Version&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;Name&amp;lt;/tt&amp;gt; are intended to uniquely identify the REST implementation represented by this particular class. Version information should be updated if any significant changes to the REST interface are implemented. This is not currently exploited, but should be. We should have an extended header that indicates the REST version that the client is expecting, and the Match process should be sensitive to this. In this way we can provide concurrent support for multiple REST versions.&lt;br /&gt;
&lt;br /&gt;
The extensive list of constant values are all held to be self-explanatory and should be used wheresoever the value they represent is required in a service implementation. This ensures consistency between the REST implementation and the REST service implementations.&lt;br /&gt;
&lt;br /&gt;
==== Functions ====&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:18:22Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Adding A New REST Service To An Existing Handler */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;br /&gt;
&lt;br /&gt;
The process for adding a new service is straightforward. The file &amp;lt;tt&amp;gt;RestTestServices.cs&amp;lt;/tt&amp;gt; serves as an example1 of what a new services class must minimally include. Key points to note are:&lt;br /&gt;
&lt;br /&gt;
# Each service class should have an associated value for &amp;lt;tt&amp;gt;qPrefix&amp;lt;/tt&amp;gt;. This should be unique for each service, as it represents the relative extension of the URI that will be matched by this service. The value supplied here may be absolute, but this is discouraged. The constructor will automatically update a relative value to reflect the absolute prefix set globally during initialization.&lt;br /&gt;
# In the case of test services the constructor loads a set of classes from a sub-directory, each of which represents a specific service implementation. For example, these may be method-related, or based upon other values contained in the supplied URI.&lt;br /&gt;
# The services constructor must register itself with the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;. It provides three values at registration time: a reference to the service method, the URI prefix that this service will match, and a reference to an &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; allocation method that will return an appropriately sub-classed instance of the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; class.&lt;br /&gt;
# Implementation of the service and allocation methods described above must be provided.&lt;br /&gt;
&lt;br /&gt;
Other methods definitions are simply part of the overall infrastructure and would be unique to a given service implementation.&lt;br /&gt;
&lt;br /&gt;
''Note that a given services class may implement zero or more services, according to its intended function. A class providing shared functionality to other services may be loaded but not register any actual handling methods. Similarly, a single services class could register multiple handling methods.''&lt;br /&gt;
&lt;br /&gt;
== REST Implementation Classes ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:18:05Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Adding A New REST Service To An Existing Handler */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;br /&gt;
&lt;br /&gt;
The process for adding a new service is straightforward. The file &amp;lt;tt&amp;gt;RestTestServices.cs&amp;lt;/tt&amp;gt; serves as an example1 of what a new services class must minimally include. Key points to note are:&lt;br /&gt;
&lt;br /&gt;
# Each service class should have an associated value for &amp;lt;tt&amp;gt;qPrefix&amp;lt;/tt&amp;gt;. This should be unique for each service, as it represents the relative extension of the URI that will be matched by this service. The value supplied here may be absolute, but this is discouraged. The constructor will automatically update a relative value to reflect the absolute prefix set globally during initialization.&lt;br /&gt;
&lt;br /&gt;
# In the case of test services the constructor loads a set of classes from a sub-directory, each of which represents a specific service implementation. For example, these may be method-related, or based upon other values contained in the supplied URI.&lt;br /&gt;
&lt;br /&gt;
# The services constructor must register itself with the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt;. It provides three values at registration time: a reference to the service method, the URI prefix that this service will match, and a reference to an &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; allocation method that will return an appropriately sub-classed instance of the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; class.&lt;br /&gt;
&lt;br /&gt;
# Implementation of the service and allocation methods described above must be provided.&lt;br /&gt;
&lt;br /&gt;
Other methods definitions are simply part of the overall infrastructure and would be unique to a given service implementation.&lt;br /&gt;
&lt;br /&gt;
''Note that a given services class may implement zero or more services, according to its intended function. A class providing shared functionality to other services may be loaded but not register any actual handling methods. Similarly, a single services class could register multiple handling methods.''&lt;br /&gt;
&lt;br /&gt;
== REST Implementation Classes ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T03:14:57Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Changes to BaseHttpServer */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
The existing OpenSim HTTP server class was modified to support plug-in modules that conform to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. Three new subroutines were added: &amp;lt;tt&amp;gt;AddHttpAgentHandler&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;RemoveHttpAgentHandler&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;TryHttpAgentHandler&amp;lt;/tt&amp;gt;; this is consistent with the way in which existing handlers are managed.&lt;br /&gt;
&lt;br /&gt;
Additionally, the &amp;lt;tt&amp;gt;HandleRequest&amp;lt;/tt&amp;gt; method was extended to include support for the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface.&lt;br /&gt;
&lt;br /&gt;
The processing of existing handlers is not affected by the new support.&lt;br /&gt;
&lt;br /&gt;
=== Plugin and Configuration Management ===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; describes the interface between OpenSim's base HTTP server and the REST implementation, a plug-in must implement this interface. Any class  that exports this interface, and that registers its handlers using the appropriate (not defined by an interface1) methods in the base HTTP server can act as a handler. Note that while the usage described here is intended to support REST, the interface itself is agnostic and may be used as the basis for any HTTP request handler.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RestPlugin.cs'''&amp;lt;/tt&amp;gt; provides a basic agent-handling superclass. An implementation of this class represents a handler from the point of view of the base HTTP server. This class implements the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface. A given implementation class need only be differentiated from the others in terms of the agent name it uses when it registers. At present, a duplicate agent (based upon supplied agent name) will not be registered; how such a failure is handled depends upon the implementation class. Aside from the name used, a given handler should be differentiated in terms of the set of request patterns that it will match; overlap is undesirable as the first match will win, and at present the order in which OpenSim loads modules is non-deterministic. The &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; class in the Inventory sub-directory is an example of an implementation class for ''RestPlugin.cs''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Inventory/RestHandler.cs'''&amp;lt;/tt&amp;gt; implements the plug-in interface described above, and also implements a local model of integrating a set of services within a single handler instance. It does this by scanning the classes included in the assembly for those that implement the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface; each such class is then initialized. This provides implementation independence from a development standpoint (adding a new service is as simple as adding a single class) whilst avoiding unnecessary overt modularization in OpenSim. This class also takes care of global configuration and initialization of the basic REST environment, i.e. It sets basic references for the OpenSim communications manager, user services, inventory services, and asset management.&lt;br /&gt;
&lt;br /&gt;
For performance reasons, and as an obligation to the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; definition, this class also implements the Match function, using pattern information registered by the individual services when they were initialized1.&lt;br /&gt;
&lt;br /&gt;
This class contains no REST specific, or service specific functionality beyond some basic initialization. This class can be used in multiple assemblies without change.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''Rest.cs'''&amp;lt;/tt&amp;gt; provides both state and functionality in support of the REST implementation. Most of the state is static and constant, a small set of static values are initialized by the &amp;lt;tt&amp;gt;RestHandler&amp;lt;/tt&amp;gt; when the plug-in is loaded. This class will only change as the REST implementation evolves and becomes more complete. I''t must not contain any service sensitive elements.'' This class may be sub-classed by a given assembly to provide global additions required by a specific set of services.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;'''RequestData.cs'''&amp;lt;/tt&amp;gt; serves as a carrier for the state associated with a request. It may be sub-classed by a given service provider in order to add service specific state and functionality, for example the inventory services currently utilize an XML extension to handle inventory specific payload interpretation and generation.&lt;br /&gt;
&lt;br /&gt;
The remaining classes in the Inventory directory provide different classes of service.&lt;br /&gt;
&lt;br /&gt;
=== Adding A New REST Service To An Existing Handler ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T01:01:33Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;br /&gt;
&lt;br /&gt;
More coming, on page 5 ... --[[User:MoHax|MoHax]] 01:01, 10 October 2008 (UTC)&lt;br /&gt;
----&lt;br /&gt;
--[[User:MoHax|MoHax]] 01:01, 10 October 2008 (UTC)&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:57:01Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{update}}&lt;br /&gt;
&lt;br /&gt;
The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:55:46Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Implementation Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg|center|thumb|400px|Illustration 1: Overall Data Flow Model]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/File:RESTOverallDataFlowModel.jpg</id>
		<title>File:RESTOverallDataFlowModel.jpg</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/File:RESTOverallDataFlowModel.jpg"/>
				<updated>2008-10-10T00:54:19Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:52:07Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Implementation Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:RESTOverallDataFlowModel.jpg]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:49:39Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Implementation Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;br /&gt;
&lt;br /&gt;
The REST implementation being described is manifest in a subset of the files contained in the &amp;lt;tt&amp;gt;ApplicationPlugins/Rest&amp;lt;/tt&amp;gt; file hierarchy. It is logically partitioned into three domains:&lt;br /&gt;
&lt;br /&gt;
* Plugin and configuration management&lt;br /&gt;
* REST implementation services&lt;br /&gt;
* REST service providers&lt;br /&gt;
&lt;br /&gt;
The objective here being to separate functionality so that the task of the service provider is made as straightforward as possible while ensuring that all services implemented using the interface are consistent in both approach and behavior.&lt;br /&gt;
&lt;br /&gt;
[[Image:Example.jpg]]&lt;br /&gt;
&lt;br /&gt;
As shown in Illustration 1: Overall Data Flow Model all requests originate, and are eventually returned to, the OpenSim HTTP server. The handler is isolated from this implementation by the &amp;lt;tt&amp;gt;IHttpAgentHandler&amp;lt;/tt&amp;gt; interface and the OSHTTP data-types. After matching, the request is passed to the appropriate handler; this relationship is defined by the &amp;lt;tt&amp;gt;IRest&amp;lt;/tt&amp;gt; interface and the &amp;lt;tt&amp;gt;RequestData&amp;lt;/tt&amp;gt; data-type.&lt;br /&gt;
&lt;br /&gt;
=== Changes to BaseHttpServer ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:45:38Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Effective URI */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                     ^^^^^&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:44:48Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Effective URI */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;&lt;br /&gt;
 http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                      ^^^^^&lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;&lt;br /&gt;
 http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:43:53Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Effective URI */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;br /&gt;
&lt;br /&gt;
From a REST perspective, the path component of the URI is viewed as a resource identification, the precise significance of which depends upon the HTTP method being used. There are subtleties here, in some cases a prefix of the path may be viewed as a functional qualification of the authority, with the remainder of the URI being a resource identification within the domain of that authority. In this document, the notion of a service corresponds to the functional qualification mechanism just described.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;prefix&amp;lt;/tt&amp;gt; value in the configuration file is used to construct the server's base prefix for REST services, as illustrated in the description of the inventory services prefix shown below:&lt;br /&gt;
&lt;br /&gt;
 http://&amp;lt;host&amp;gt;:&amp;lt;port&amp;gt;/admin/inventory&lt;br /&gt;
                      ^^^^^&lt;br /&gt;
&lt;br /&gt;
In this URI &amp;lt;tt&amp;gt;/admin&amp;lt;/tt&amp;gt; is the base prefix, and &amp;lt;tt&amp;gt;/inventory&amp;lt;/tt&amp;gt; is a prefix extension that identifies the inventory service handler.&lt;br /&gt;
&lt;br /&gt;
All requests that have an &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; prefix will be passed to the inventory handler. The prefix must be followed by the name of the avatar that owns the inventory in question. For example:&lt;br /&gt;
&lt;br /&gt;
 http://localhost:9000/admin/inventory/Alan Webb&lt;br /&gt;
&lt;br /&gt;
Assuming the GET method, then this will return Alan Webb's inventory catalog, as XML data in the response payload, for example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;Inventory&amp;gt;&lt;br /&gt;
&amp;lt;Folder name = “My Inventory” uuid=”11111111-...-111111111111” ....&lt;br /&gt;
        &amp;lt;Folder name=”Objects” uuid=....&lt;br /&gt;
        ....&lt;br /&gt;
        &amp;lt;/Folder&amp;gt;&lt;br /&gt;
    &amp;lt;/Folder&amp;gt;&lt;br /&gt;
&amp;lt;/Inventory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In this case &amp;lt;tt&amp;gt;/admin/inventory&amp;lt;/tt&amp;gt; identiifes the service, and &amp;lt;tt&amp;gt;/Alan Webb&amp;lt;/tt&amp;gt; is the resource specification component of the path.&lt;br /&gt;
&lt;br /&gt;
== Implementation Overview ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:39:08Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Configuration Parameters */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:37:28Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;br /&gt;
&lt;br /&gt;
== REST Inventory Support ==&lt;br /&gt;
&lt;br /&gt;
The REST support in OpenSim is separated into a number of functional components, all of which live in the OpenSim/ApplicationPlugins/Rest hierarchy.&lt;br /&gt;
&lt;br /&gt;
# Plug-in management. E.g. RestPlugin.cs and Inventory/RestHandler.cs&lt;br /&gt;
# Service management: Inventory/RestHandler.cs&lt;br /&gt;
# REST implementation: RequestData.cs, Rest.cs&lt;br /&gt;
# Service implementations: Inventory/RestInventoryServices.cs, Inventory/RestAssetServices.cs, etc.&lt;br /&gt;
&lt;br /&gt;
This separation serves a number of purposes:&lt;br /&gt;
&lt;br /&gt;
* it limits the sensitivity of each component to implementation changes in the others&lt;br /&gt;
* it simplifies the task of service implementation by “hiding” infrastructure&lt;br /&gt;
* it helps make services consistent by sharing a single implementation of REST related tasks&lt;br /&gt;
&lt;br /&gt;
The design intention is that each subdirectory in the REST hierarchy, I.e. Inventory, corresponds to a distinct REST handler assembly consisting of service management and one or more service implementations. The Inventory directory is one example of such an assembly.&lt;br /&gt;
&lt;br /&gt;
=== Configuration Parameters ===&lt;br /&gt;
&lt;br /&gt;
In order for the REST handlers to be loaded and effective, statements must be added to the OpenSim.ini file. OpenSim reads the initialization file during start-up. This file is partitioned into various functional domains, e.g.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&lt;br /&gt;
[Startup]&lt;br /&gt;
gridmode = false&lt;br /&gt;
physics = basicphysics&lt;br /&gt;
&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = false&lt;br /&gt;
&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = false&lt;br /&gt;
&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;tt&amp;gt;RestPlugins&amp;lt;/tt&amp;gt; partition affects REST handlers in general and supports the following entries:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&lt;br /&gt;
[RestPlugins]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
god_key = &amp;lt;string&amp;gt; || “”&lt;br /&gt;
prefix  = &amp;lt;string&amp;gt;   || “/admin”&lt;br /&gt;
&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Only &amp;lt;tt&amp;gt;enabled=true&amp;lt;/tt&amp;gt; is necessary to enable REST processing. &lt;br /&gt;
&lt;br /&gt;
Additionally, REST inventory processing currently requires that the following partition be defined:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tt&amp;gt;&lt;br /&gt;
[RestHandler]&lt;br /&gt;
enabled = true|false || false&lt;br /&gt;
authenticate = true|false || true&lt;br /&gt;
extended-escape = true|false || true&lt;br /&gt;
realm = &amp;lt;string&amp;gt; || “OpenSim REST”&lt;br /&gt;
dump-asset = true|false || false&lt;br /&gt;
dump-line-size = int%8 || 32&lt;br /&gt;
path-fill = true|false || false&lt;br /&gt;
&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The partition name corresponds to the &amp;lt;tt&amp;gt;ConfigName&amp;lt;/tt&amp;gt; value specified in the plug-in subclass, I.e. RestHandler.cs.&lt;br /&gt;
&lt;br /&gt;
Again, only the enabled=true entry must be provided to enable the inventory handler; all other defaults are acceptable for normal operation. The meanings of these values will become apparent in the rest of the document.&lt;br /&gt;
&lt;br /&gt;
When the server starts, the REST handler will publish several messages indicating which configuration values are in effect.&lt;br /&gt;
&lt;br /&gt;
=== Effective URI ===&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Help</id>
		<title>Help</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Help"/>
				<updated>2008-10-10T00:30:01Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The best way to learn about and contribute to the project is to log into our IRC channel, located on irc.freenode.net in [irc://irc.freenode.net/opensim #opensim] (for users) and [irc://irc.freenode.net/opensim-dev #opensim-dev] (for developers).&lt;br /&gt;
&lt;br /&gt;
Perhaps you were looking for [http://www.mediawiki.org/wiki/Help:Formatting#Other_formatting help with MediaWiki formatting].&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Help</id>
		<title>Help</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Help"/>
				<updated>2008-10-10T00:27:53Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The best way to learn about and contribute to the project is to log into our IRC channel, located on irc.freenode.net in [irc://irc.freenode.net/opensim #opensim] (for users) and [irc://irc.freenode.net/opensim-dev #opensim-dev] (for developers).&lt;br /&gt;
&lt;br /&gt;
Perhaps you were looking for [[Help:Editing]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-10T00:10:33Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access. --[[User:MoHax|MoHax]] 00:10, 10 October 2008 (UTC)&lt;br /&gt;
&lt;br /&gt;
There are a number of REST interfaces1 implemented within OpenSim. This document describes the work done to support specific interactions required in support of external application integration. XML is used to encode the payloads associated with these requests. The specific XML used is documented as an appendix, this is an interim specification.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-09T23:52:02Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's ''OpenSim REST Support'' Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;br /&gt;
&lt;br /&gt;
The notion of Representational State Transfer (REST) was introduced by Roy Fielding in his doctoral dissertation in 2000. It is essentially an architectural concept rather than a protocol, and this has led to a variety of implementations, all of which might claim to be compliant REST implementations.&lt;br /&gt;
&lt;br /&gt;
A REST interface is built upon the HTTP protocol, making use of the four principle methods defined therein: GET, PUT, POST, and DELETE. A fifth method HEAD is also supported, but that is really just a semantic variation of GET. The TRACE and OPTIONS methods have a less fundamental role. No other protocol is involved.&lt;br /&gt;
&lt;br /&gt;
Note that REST does not specify the nature of the payload either sent or received. The interface associated with this document uses XML meta-data to manage an arbitrary payload. The need for a schema document to give form to this XML will be dealt with as a separate discussion.&lt;br /&gt;
&lt;br /&gt;
Of particular significance is the understood meaning of the methods themselves, which is (and must be) as defined by the HTTP specification:&lt;br /&gt;
&lt;br /&gt;
* '''GET''' retrieves the information identified by the associated URI and returns it to the requester. GET is idempotent. If the URI identifies a process, then it is the output of that process which is returned, and not the source text of that process. GET is conditional when the headers include any of the If headers. GET is partial if a range related header is included. The results of GET may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''HEAD''' is functionally equivalent to GET except that the payload is not included in the response. The result of a HEAD request may be able to be cached.&lt;br /&gt;
&lt;br /&gt;
* '''POST''' requests that the server accept the payload as a new entity, subordinate to the existing entity identified by the URI. POST places requirements upon session capabilities in the server insofar as it requires persistent connection and flow control capabilities.&lt;br /&gt;
&lt;br /&gt;
* '''PUT''' indicates that the payload should be stored on the server under1 the resource named by the URI. If the named resource already exists, then the payload is considered to be a modified version of that resource. If the named resource does not exist, then it should be created by the server.&lt;br /&gt;
&lt;br /&gt;
* '''DELETE''' requests that the server delete the resource identified by the URI.&lt;br /&gt;
&lt;br /&gt;
Other methods (TRACE, OPTIONS, CONNECT) may be supported, but are not fundamental to the principles of REST. Use of these methods also implies specific requirements in terms of how the response codes should be used.&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/REST</id>
		<title>REST</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/REST"/>
				<updated>2008-10-09T23:47:10Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: New page: The following is taken from Alan M Webb's OpenSim REST Support Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful O...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is taken from Alan M Webb's OpenSim REST Support Draft document dated 8/18/08. The information here and specification are works in progress but provide the basis for useful OpenSim integrations including content input and retrieval without direct DB access.&lt;br /&gt;
&lt;br /&gt;
== What is REST? ==&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Configuration</id>
		<title>Configuration</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Configuration"/>
				<updated>2008-10-07T19:17:36Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Standalone vs. Grid */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==OpenSim configuration file==&lt;br /&gt;
The simulator configuration is managed using a file called [[OpenSim.ini]]. This file is used regardless of whether the sim is running in standalone or grid mode. Detailed information on the options available for setttings in this file can be found [[OpenSim.ini|here]].&lt;br /&gt;
&lt;br /&gt;
==Database==&lt;br /&gt;
Opensim's supports the following database-engines:&lt;br /&gt;
* SQLite (default - a lightweight database that comes bundled with OpenSim and can be used without requiring any extra configuration.  It is mostly intended to get you up and running quickly, not for production use.)&lt;br /&gt;
* MySQL (fully supported)&lt;br /&gt;
* MSSQL (partially supported - some recent OpenSim features may not yet be implemented)&lt;br /&gt;
&lt;br /&gt;
More information on database support can be found on the [[OpenSim Database support]] page.&lt;br /&gt;
&lt;br /&gt;
==Script engine==&lt;br /&gt;
OpenSim supports multiple script engines. See [[ScriptEngines]] for details&lt;br /&gt;
&lt;br /&gt;
==Standalone vs. Grid==&lt;br /&gt;
We recommend that you first get OpenSim running in standalone mode before you attempt to connect it to a grid, either your own grid or a public grid.  An OpenSim configuration consists of regions (run by region simulators) and 5 core backend services (which manage users, the grid, assets, inventories, and grid-wide messaging, collectively known as UGAIM).&lt;br /&gt;
&lt;br /&gt;
A system running in '''standalone mode''' (that is, one  with OpenSim.ini configured such that gridmode = false) -- also known as &amp;quot;sandbox mode&amp;quot; -- runs everything (all UGAIM services and one or more regions) in a single executable (OpenSim.exe).  External regions cannot be added to an OpenSim running in this mode.&lt;br /&gt;
&lt;br /&gt;
In '''grid mode''', the five services ([[User Server|User]], [[Grid Server|Grid]], [[Asset Server|Asset]], [[Inventory Server|Inventory]], [[Messaging Server|Messaging]], or UGAIM) are each started as separate executables.  This means that they can be run either on the same machine or spread out across multiple computers.  In this mode, OpenSim.exe serves one or more regions, which communicate with the core servers.  This mode even allows region servers run by other people on their own machines to connect, if you wish.&lt;br /&gt;
&lt;br /&gt;
Naturally, this means that running in grid mode is somewhat more complicated than running in standalone mode.  It requires an understanding of UUID, X,Y location, server handshake passwords, master avatars, and a couple of other settings. These are not difficult, but do require a little more care in setting things up.&lt;br /&gt;
&lt;br /&gt;
If you want to run a grid of your own (either private or public) you would start the core services up before connecting a region simulator.  If you want to connect your region server to a grid that someone else is running, you need only start the region server in grid mode (with the necessary security keys and location information mentioned in the last paragraph).&lt;br /&gt;
&lt;br /&gt;
OpenSim.exe responds to various command line arguments. These include &amp;quot;-inifile&amp;quot;, &amp;quot;-configfile&amp;quot;, &amp;quot;-gridmode&amp;quot;, &amp;quot;-physics&amp;quot;, &amp;quot;-config&amp;quot; &amp;amp; &amp;quot;-noverbose&amp;quot;. When starting OpenSim in either Windows or Linux, one could, for example, add &amp;quot;-physics=OpenDynamicsEngine&amp;quot; to run the OpenDynamicsEngine instead of basicphysics, or use &amp;quot;-gridmode=true&amp;quot; to force opensim.exe to run as a region server (the rest of the grid services have their own executables).  As many of these settings are normally controlled by OpenSim.ini, most users (especially in standalone mode) will not add any command line arguments.&lt;br /&gt;
&lt;br /&gt;
===Standalone mode===&lt;br /&gt;
&lt;br /&gt;
When you start OpenSim in standalone mode, it will ask you several questions at the console. The first set of prompts that start with &amp;quot;NETWORK SERVERS INFO&amp;quot;, you can just hit return to accept the defaults if you will be running in standalone mode. The prompts that start with &amp;quot;DEFAULT REGION CONFIG&amp;quot; are where you need to start paying attention. Some are self-explanatory. Here are explanations for the others:&amp;lt;br&amp;gt;&lt;br /&gt;
* Grid Location. OpenSim regions can be placed anywhere on a 65536 by 65536 grid. In standalone mode, it is safe to leave these X and Y locations at their defaults for the first region (additional regions will need different coordinates, of course).&lt;br /&gt;
* Filename for local storage. Safe to leave at default.&lt;br /&gt;
* Internal IP address; This should always be 0.0.0.0 (0.0.0.0 means &amp;quot;listen for connections on any interface&amp;quot;, basically a wildcard)&lt;br /&gt;
* Internal IP port for incoming UDP client connection. You can make this any port you want, but it is safe to leave at the default 9000.&lt;br /&gt;
* External host name. If you will only be attaching to your sim from a SecondLife client on the same machine, you can leave this at the default 127.0.0.1. If you will be wanting to connect to it from a client on another machine, this should be the IP address or hostname of the machine you are running this sim on. N.B - It appears that this must actually be the External Host IP Address, not the Domain Name.&lt;br /&gt;
To connect to your new sim, start up secondlife with the following command line switches:&lt;br /&gt;
 -loginuri http://127.0.0.1:9000/ -loginpage http://127.0.0.1:9000/?method=login &lt;br /&gt;
This assumes you are running the secondlife client on the same box. If you are running it on a separate box, substitute the IP address of your sim machine.&amp;lt;br&amp;gt;&lt;br /&gt;
To create a user:&amp;lt;br&amp;gt;&lt;br /&gt;
type ''create user &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; &amp;lt;password&amp;gt; &amp;lt;x_loc&amp;gt; &amp;lt;y_loc&amp;gt;'' in the server console.&lt;br /&gt;
&lt;br /&gt;
===Grid mode===&lt;br /&gt;
You want to run your own grid. Great! Assuming that you already got your sim running in standalone mode, here is what you need to do:&amp;lt;br&amp;gt;&lt;br /&gt;
1. Current builds of OpenSim grid mode are using mysql to store the grid information. You must have this installed and configured if you want to run your own grid. See [[mysql-config]] for more information.&amp;lt;br&amp;gt;&lt;br /&gt;
2. Four of the servers should be started in a certain order. UGAI: UserServer, GridServer, AssetServer, InventoryServer. The MessagingServer can be started at any point after the GridServer, and the RegionServer(s) should always come last.  These are all found in the bin directory. In windows, you can just double-click on the executables to start them. In Linux and Mac OS X type &amp;quot;mono filename&amp;quot; from a prompt. The executable names, in order, are:&lt;br /&gt;
 OpenSim.Grid.UserServer.exe&lt;br /&gt;
 OpenSim.Grid.GridServer.exe&lt;br /&gt;
 OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
3. Start the UserServer. If you will be running the GridServer on the same box, hit enter to accept the defaults, until it gives you the prompt&lt;br /&gt;
 OpenUser#&lt;br /&gt;
This is the main prompt for the user server. If you will be running the GridServer on another box, change the Default Grid Server URI as appropriate.&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start the GridServer. Again, you can hit return at all the prompts if you are running them all on the same machine. If not, change the URIs for the Asset Server and User server to point to where you are running them. You will finally get to the console prompt for the GridServer which looks like this:&lt;br /&gt;
 OpenGrid#&lt;br /&gt;
5. Start the AssetServer. The console prompt for this server will be:&lt;br /&gt;
 OpenAsset#&lt;br /&gt;
6. Start the InventoryServer. The console prompt for this server will be:&lt;br /&gt;
 INVENTORY#&lt;br /&gt;
7. Start the MessagingServer.  The console prompt for this is:&lt;br /&gt;
 Messaging#&lt;br /&gt;
8. If you are running all of these servers on the same box, which would be the normal configuration, you should be ready to start up your sim.  The mode that OpenSim.exe starts in is normally controlled by a setting in your OpenSim.ini.  It defaults to standalone mode if that setting is not specified or the file is not found.  If you wish, you can force opensim to start in gridmode on the command line as follows:&lt;br /&gt;
 OpenSim.exe -gridmode=true&lt;br /&gt;
or:&lt;br /&gt;
 mono OpenSim.exe -gridmode=true&lt;br /&gt;
With any luck, everything will come up without too many errors.&amp;lt;br&amp;gt;&lt;br /&gt;
9. Go to the UserServer console, and type 'create user' to create a new avatar. It will prompt you for the name and password, and the X and Y of the sim that should be his home location. Use 1000 and 1000, or wherever you told your sim to live when you brought it up in standalone mode. At the console of any of these servers, you should be able to type 'help' to get a list of commands.&lt;br /&gt;
&lt;br /&gt;
You should now be able to connect to your new grid with your secondlife client. You need to tell your client to point at the UserServer rather than directly at the sim, though:&lt;br /&gt;
 secondlife -loginuri http://127.0.0.1:8002/&lt;br /&gt;
8002 is the default port for the UserServer, and that IP address should be changed to the server you are running the UserServer on, if they are not all on the same box.  Happy OpenSimming!&amp;lt;br&amp;gt;&lt;br /&gt;
''Note: if you are using Windows Vista, remember to start servers as Admin. If not it will prompt you an error in console like &amp;quot;Error - Access denied&amp;quot;''&lt;br /&gt;
&lt;br /&gt;
==Multiple regions==&lt;br /&gt;
&lt;br /&gt;
Using Physical Prim with the OpenDynamicsEngine on *nix, it's recommended that you set your stack reserve level higher then default with the following command;&lt;br /&gt;
&amp;lt;tt&amp;gt;ulimit -s 262144&amp;lt;/tt&amp;gt; Or, run the opensim-ode.sh to start up OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
A powerful region generator is available at: [[RegionGenerator]]&lt;br /&gt;
&lt;br /&gt;
For running multiple regions on the same box, you simply make multiple copies of the 'default.xml' file inside the &amp;lt;tt&amp;gt;bin/Regions/&amp;lt;/tt&amp;gt; directory.  You can do this using the script &amp;lt;tt&amp;gt;make.php&amp;lt;/tt&amp;gt; in &amp;lt;tt&amp;gt;share/regions&amp;lt;/tt&amp;gt;, or you can generate the files by hand.&lt;br /&gt;
&lt;br /&gt;
If you want to create the files by hand:&lt;br /&gt;
&lt;br /&gt;
:first copy the default.xml file in the &amp;lt;tt&amp;gt;bin/Regions&amp;lt;/tt&amp;gt; directory, and name them anything you want (I name mine region.x.y.xml, where region is the name of the region, and x and y are the grid coords.)&lt;br /&gt;
:Open each xml file and edit the uuid (a generator can be found at [http://www.famkruithof.net/uuid/uuidgen uuidgen webpage] or on unix, use the uuidgen command), region name, x &amp;amp; y positions, and internal ip port. IMPORTANT!  The UUID, name, and grid coordinates ''must'' be unique for each region on a grid.  The port assignment must be unique for each region that is running on a particular machine.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that &amp;lt;tt&amp;gt;sim_location_x&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;sim_location_y&amp;lt;/tt&amp;gt; should be adjacent integers if you want your regions to be adjacent, so you can run back and forth between them.  '''IMPORTANT: THESE GRID COORDINATES ARE ''NOT'' IN METERS.  THEY ARE SIM POSITIONS.'''  (1000, 1000) is next to (1001,1000), (1000, 1001), and so forth.  1256, 2000, 2048 and similar values are '''not''' adjacent to 1000, they are very far away, so you would not see your sims from one another.&lt;br /&gt;
&lt;br /&gt;
Once you have 2 or more xml files in the bin/Regions folder, running a ''single'' copy of &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; will start up all of your sims! If you come across any errors, there is most likely an error in your xml files.&lt;br /&gt;
&lt;br /&gt;
As of 6-Feb-2008, take care NOT to leave editor backup copies of the files in this directory e.g. emacs style backup names like Regionname.xml~. These are loaded by opensim.exe as if they are legitimate region descriptions, and will therefore give errors indicating you are trying to re-use the socket for that region.&lt;br /&gt;
&lt;br /&gt;
==Attaching your sim to someone else's grid==&lt;br /&gt;
To set up the region server (i.e., &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt;) to connect to an external grid, you should edit the &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file in the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory.  In that file, there is a &amp;lt;tt&amp;gt;[Network]&amp;lt;/tt&amp;gt; section with URLs for the grid, user, and asset servers, as well as send and receive keys (for a basic level of security).  The addresses and send/receive keys will vary depending on the grid you are connecting to, and the grid operator should tell you what values to use.&lt;br /&gt;
&lt;br /&gt;
The other file you may have to change is in your &amp;lt;tt&amp;gt;bin/Regions&amp;lt;/tt&amp;gt; directory. This is where your individual region config files are. If you only have one region, it will by default be called &amp;lt;tt&amp;gt;default.xml&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This can be edited with any text editor. The grid owner may tell you what X and Y location you can place your sim at (you can't have multiple sims at the same location on the grid). If so, the fields you will need to change in this file are &amp;lt;tt&amp;gt;sim_location_x&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;sim_location_y&amp;lt;/tt&amp;gt;.  And the &amp;lt;tt&amp;gt;external_host_name&amp;lt;/tt&amp;gt; should be set to the hostname or IP address of your simulation server (i.e., the machine that is running &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt;).&lt;br /&gt;
A list of public grids that you can attach your sim to is at [[OpenSim: Grids]]&lt;br /&gt;
&lt;br /&gt;
==Running==&lt;br /&gt;
&lt;br /&gt;
===StandAlone===&lt;br /&gt;
'''&amp;lt;u&amp;gt;Windows&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
On Windows Vista, it may be necessary to explicitly &amp;quot;Run as administrator&amp;quot; for opensim.exe to accept connections from a client, even when running as an administrator user. Navigate to the opensim\bin directory, right click opensim.exe, and select &amp;quot;Run as administrator&amp;quot;.&lt;br /&gt;
Connect: opensim://localhost:9000 , or opensim://127.0.0.1:9000, or opensim://myipadress:9000&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Linux&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;OSX&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
===Local Grid===&lt;br /&gt;
'''&amp;lt;u&amp;gt;Windows&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 OpenSim.Grid.UserServer.exe&lt;br /&gt;
 OpenSim.Grid.GridServer.exe&lt;br /&gt;
 OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Linux&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.Grid.UserServer.exe&lt;br /&gt;
 mono OpenSim.Grid.GridServer.exe&lt;br /&gt;
 mono OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 mono OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 mono OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;OSX&amp;lt;/u&amp;gt;''''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.Grid.UserServer.exe&lt;br /&gt;
 mono OpenSim.Grid.GridServer.exe&lt;br /&gt;
 mono OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 mono OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 mono OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
Connect: opensim://myipaddress:9000&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Configuration</id>
		<title>Configuration</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Configuration"/>
				<updated>2008-10-07T19:07:43Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Standalone vs. Grid */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==OpenSim configuration file==&lt;br /&gt;
The simulator configuration is managed using a file called [[OpenSim.ini]]. This file is used regardless of whether the sim is running in standalone or grid mode. Detailed information on the options available for setttings in this file can be found [[OpenSim.ini|here]].&lt;br /&gt;
&lt;br /&gt;
==Database==&lt;br /&gt;
Opensim's supports the following database-engines:&lt;br /&gt;
* SQLite (default - a lightweight database that comes bundled with OpenSim and can be used without requiring any extra configuration.  It is mostly intended to get you up and running quickly, not for production use.)&lt;br /&gt;
* MySQL (fully supported)&lt;br /&gt;
* MSSQL (partially supported - some recent OpenSim features may not yet be implemented)&lt;br /&gt;
&lt;br /&gt;
More information on database support can be found on the [[OpenSim Database support]] page.&lt;br /&gt;
&lt;br /&gt;
==Script engine==&lt;br /&gt;
OpenSim supports multiple script engines. See [[ScriptEngines]] for details&lt;br /&gt;
&lt;br /&gt;
==Standalone vs. Grid==&lt;br /&gt;
We recommend that you first get OpenSim running in standalone mode before you attempt to connect it to a grid, either your own grid or a public grid.  An OpenSim configuration consists of regions (run by region simulators) and 5 core backend services (which manage users, the grid, assets, inventories, and grid-wide messaging, collectively known as UGAIM).&lt;br /&gt;
&lt;br /&gt;
A system running in '''standalone mode''' (that is, one  with OpenSim.ini configured such that gridmode = false) -- also known as &amp;quot;sandbox mode&amp;quot; -- runs everything (all UGAIM services and one or more regions) in a single executable (OpenSim.exe).  External regions cannot be added to an OpenSim running in this mode.&lt;br /&gt;
&lt;br /&gt;
In '''grid mode''', the five services (User, Grid, Asset, Inventory, Messaging, or UGAIM) are each started as separate executables.  This means that they can be run either on the same machine or spread out across multiple computers.  In this mode, OpenSim.exe serves one or more regions, which communicate with the core servers.  This mode even allows region servers run by other people on their own machines to connect, if you wish.&lt;br /&gt;
&lt;br /&gt;
Naturally, this means that running in grid mode is somewhat more complicated than running in standalone mode.  It requires an understanding of UUID, X,Y location, server handshake passwords, master avatars, and a couple of other settings. These are not difficult, but do require a little more care in setting things up.&lt;br /&gt;
&lt;br /&gt;
If you want to run a grid of your own (either private or public) you would start the core services up before connecting a region simulator.  If you want to connect your region server to a grid that someone else is running, you need only start the region server in grid mode (with the necessary security keys and location information mentioned in the last paragraph).&lt;br /&gt;
&lt;br /&gt;
OpenSim.exe responds to various command line arguments. These include &amp;quot;-inifile&amp;quot;, &amp;quot;-configfile&amp;quot;, &amp;quot;-gridmode&amp;quot;, &amp;quot;-physics&amp;quot;, &amp;quot;-config&amp;quot; &amp;amp; &amp;quot;-noverbose&amp;quot;. When starting OpenSim in either Windows or Linux, one could, for example, add &amp;quot;-physics=OpenDynamicsEngine&amp;quot; to run the OpenDynamicsEngine instead of basicphysics, or use &amp;quot;-gridmode=true&amp;quot; to force opensim.exe to run as a region server (the rest of the grid services have their own executables).  As many of these settings are normally controlled by OpenSim.ini, most users (especially in standalone mode) will not add any command line arguments.&lt;br /&gt;
&lt;br /&gt;
===Standalone mode===&lt;br /&gt;
&lt;br /&gt;
When you start OpenSim in standalone mode, it will ask you several questions at the console. The first set of prompts that start with &amp;quot;NETWORK SERVERS INFO&amp;quot;, you can just hit return to accept the defaults if you will be running in standalone mode. The prompts that start with &amp;quot;DEFAULT REGION CONFIG&amp;quot; are where you need to start paying attention. Some are self-explanatory. Here are explanations for the others:&amp;lt;br&amp;gt;&lt;br /&gt;
* Grid Location. OpenSim regions can be placed anywhere on a 65536 by 65536 grid. In standalone mode, it is safe to leave these X and Y locations at their defaults for the first region (additional regions will need different coordinates, of course).&lt;br /&gt;
* Filename for local storage. Safe to leave at default.&lt;br /&gt;
* Internal IP address; This should always be 0.0.0.0 (0.0.0.0 means &amp;quot;listen for connections on any interface&amp;quot;, basically a wildcard)&lt;br /&gt;
* Internal IP port for incoming UDP client connection. You can make this any port you want, but it is safe to leave at the default 9000.&lt;br /&gt;
* External host name. If you will only be attaching to your sim from a SecondLife client on the same machine, you can leave this at the default 127.0.0.1. If you will be wanting to connect to it from a client on another machine, this should be the IP address or hostname of the machine you are running this sim on. N.B - It appears that this must actually be the External Host IP Address, not the Domain Name.&lt;br /&gt;
To connect to your new sim, start up secondlife with the following command line switches:&lt;br /&gt;
 -loginuri http://127.0.0.1:9000/ -loginpage http://127.0.0.1:9000/?method=login &lt;br /&gt;
This assumes you are running the secondlife client on the same box. If you are running it on a separate box, substitute the IP address of your sim machine.&amp;lt;br&amp;gt;&lt;br /&gt;
To create a user:&amp;lt;br&amp;gt;&lt;br /&gt;
type ''create user &amp;lt;first&amp;gt; &amp;lt;last&amp;gt; &amp;lt;password&amp;gt; &amp;lt;x_loc&amp;gt; &amp;lt;y_loc&amp;gt;'' in the server console.&lt;br /&gt;
&lt;br /&gt;
===Grid mode===&lt;br /&gt;
You want to run your own grid. Great! Assuming that you already got your sim running in standalone mode, here is what you need to do:&amp;lt;br&amp;gt;&lt;br /&gt;
1. Current builds of OpenSim grid mode are using mysql to store the grid information. You must have this installed and configured if you want to run your own grid. See [[mysql-config]] for more information.&amp;lt;br&amp;gt;&lt;br /&gt;
2. Four of the servers should be started in a certain order. UGAI: UserServer, GridServer, AssetServer, InventoryServer. The MessagingServer can be started at any point after the GridServer, and the RegionServer(s) should always come last.  These are all found in the bin directory. In windows, you can just double-click on the executables to start them. In Linux and Mac OS X type &amp;quot;mono filename&amp;quot; from a prompt. The executable names, in order, are:&lt;br /&gt;
 OpenSim.Grid.UserServer.exe&lt;br /&gt;
 OpenSim.Grid.GridServer.exe&lt;br /&gt;
 OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
3. Start the UserServer. If you will be running the GridServer on the same box, hit enter to accept the defaults, until it gives you the prompt&lt;br /&gt;
 OpenUser#&lt;br /&gt;
This is the main prompt for the user server. If you will be running the GridServer on another box, change the Default Grid Server URI as appropriate.&amp;lt;br&amp;gt;&lt;br /&gt;
4. Start the GridServer. Again, you can hit return at all the prompts if you are running them all on the same machine. If not, change the URIs for the Asset Server and User server to point to where you are running them. You will finally get to the console prompt for the GridServer which looks like this:&lt;br /&gt;
 OpenGrid#&lt;br /&gt;
5. Start the AssetServer. The console prompt for this server will be:&lt;br /&gt;
 OpenAsset#&lt;br /&gt;
6. Start the InventoryServer. The console prompt for this server will be:&lt;br /&gt;
 INVENTORY#&lt;br /&gt;
7. Start the MessagingServer.  The console prompt for this is:&lt;br /&gt;
 Messaging#&lt;br /&gt;
8. If you are running all of these servers on the same box, which would be the normal configuration, you should be ready to start up your sim.  The mode that OpenSim.exe starts in is normally controlled by a setting in your OpenSim.ini.  It defaults to standalone mode if that setting is not specified or the file is not found.  If you wish, you can force opensim to start in gridmode on the command line as follows:&lt;br /&gt;
 OpenSim.exe -gridmode=true&lt;br /&gt;
or:&lt;br /&gt;
 mono OpenSim.exe -gridmode=true&lt;br /&gt;
With any luck, everything will come up without too many errors.&amp;lt;br&amp;gt;&lt;br /&gt;
9. Go to the UserServer console, and type 'create user' to create a new avatar. It will prompt you for the name and password, and the X and Y of the sim that should be his home location. Use 1000 and 1000, or wherever you told your sim to live when you brought it up in standalone mode. At the console of any of these servers, you should be able to type 'help' to get a list of commands.&lt;br /&gt;
&lt;br /&gt;
You should now be able to connect to your new grid with your secondlife client. You need to tell your client to point at the UserServer rather than directly at the sim, though:&lt;br /&gt;
 secondlife -loginuri http://127.0.0.1:8002/&lt;br /&gt;
8002 is the default port for the UserServer, and that IP address should be changed to the server you are running the UserServer on, if they are not all on the same box.  Happy OpenSimming!&amp;lt;br&amp;gt;&lt;br /&gt;
''Note: if you are using Windows Vista, remember to start servers as Admin. If not it will prompt you an error in console like &amp;quot;Error - Access denied&amp;quot;''&lt;br /&gt;
&lt;br /&gt;
==Multiple regions==&lt;br /&gt;
&lt;br /&gt;
Using Physical Prim with the OpenDynamicsEngine on *nix, it's recommended that you set your stack reserve level higher then default with the following command;&lt;br /&gt;
&amp;lt;tt&amp;gt;ulimit -s 262144&amp;lt;/tt&amp;gt; Or, run the opensim-ode.sh to start up OpenSimulator.&lt;br /&gt;
&lt;br /&gt;
A powerful region generator is available at: [[RegionGenerator]]&lt;br /&gt;
&lt;br /&gt;
For running multiple regions on the same box, you simply make multiple copies of the 'default.xml' file inside the &amp;lt;tt&amp;gt;bin/Regions/&amp;lt;/tt&amp;gt; directory.  You can do this using the script &amp;lt;tt&amp;gt;make.php&amp;lt;/tt&amp;gt; in &amp;lt;tt&amp;gt;share/regions&amp;lt;/tt&amp;gt;, or you can generate the files by hand.&lt;br /&gt;
&lt;br /&gt;
If you want to create the files by hand:&lt;br /&gt;
&lt;br /&gt;
:first copy the default.xml file in the &amp;lt;tt&amp;gt;bin/Regions&amp;lt;/tt&amp;gt; directory, and name them anything you want (I name mine region.x.y.xml, where region is the name of the region, and x and y are the grid coords.)&lt;br /&gt;
:Open each xml file and edit the uuid (a generator can be found at [http://www.famkruithof.net/uuid/uuidgen uuidgen webpage] or on unix, use the uuidgen command), region name, x &amp;amp; y positions, and internal ip port. IMPORTANT!  The UUID, name, and grid coordinates ''must'' be unique for each region on a grid.  The port assignment must be unique for each region that is running on a particular machine.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that &amp;lt;tt&amp;gt;sim_location_x&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;sim_location_y&amp;lt;/tt&amp;gt; should be adjacent integers if you want your regions to be adjacent, so you can run back and forth between them.  '''IMPORTANT: THESE GRID COORDINATES ARE ''NOT'' IN METERS.  THEY ARE SIM POSITIONS.'''  (1000, 1000) is next to (1001,1000), (1000, 1001), and so forth.  1256, 2000, 2048 and similar values are '''not''' adjacent to 1000, they are very far away, so you would not see your sims from one another.&lt;br /&gt;
&lt;br /&gt;
Once you have 2 or more xml files in the bin/Regions folder, running a ''single'' copy of &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; will start up all of your sims! If you come across any errors, there is most likely an error in your xml files.&lt;br /&gt;
&lt;br /&gt;
As of 6-Feb-2008, take care NOT to leave editor backup copies of the files in this directory e.g. emacs style backup names like Regionname.xml~. These are loaded by opensim.exe as if they are legitimate region descriptions, and will therefore give errors indicating you are trying to re-use the socket for that region.&lt;br /&gt;
&lt;br /&gt;
==Attaching your sim to someone else's grid==&lt;br /&gt;
To set up the region server (i.e., &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt;) to connect to an external grid, you should edit the &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file in the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory.  In that file, there is a &amp;lt;tt&amp;gt;[Network]&amp;lt;/tt&amp;gt; section with URLs for the grid, user, and asset servers, as well as send and receive keys (for a basic level of security).  The addresses and send/receive keys will vary depending on the grid you are connecting to, and the grid operator should tell you what values to use.&lt;br /&gt;
&lt;br /&gt;
The other file you may have to change is in your &amp;lt;tt&amp;gt;bin/Regions&amp;lt;/tt&amp;gt; directory. This is where your individual region config files are. If you only have one region, it will by default be called &amp;lt;tt&amp;gt;default.xml&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This can be edited with any text editor. The grid owner may tell you what X and Y location you can place your sim at (you can't have multiple sims at the same location on the grid). If so, the fields you will need to change in this file are &amp;lt;tt&amp;gt;sim_location_x&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;sim_location_y&amp;lt;/tt&amp;gt;.  And the &amp;lt;tt&amp;gt;external_host_name&amp;lt;/tt&amp;gt; should be set to the hostname or IP address of your simulation server (i.e., the machine that is running &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt;).&lt;br /&gt;
A list of public grids that you can attach your sim to is at [[OpenSim: Grids]]&lt;br /&gt;
&lt;br /&gt;
==Running==&lt;br /&gt;
&lt;br /&gt;
===StandAlone===&lt;br /&gt;
'''&amp;lt;u&amp;gt;Windows&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
On Windows Vista, it may be necessary to explicitly &amp;quot;Run as administrator&amp;quot; for opensim.exe to accept connections from a client, even when running as an administrator user. Navigate to the opensim\bin directory, right click opensim.exe, and select &amp;quot;Run as administrator&amp;quot;.&lt;br /&gt;
Connect: opensim://localhost:9000 , or opensim://127.0.0.1:9000, or opensim://myipadress:9000&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Linux&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;OSX&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
===Local Grid===&lt;br /&gt;
'''&amp;lt;u&amp;gt;Windows&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 OpenSim.Grid.UserServer.exe&lt;br /&gt;
 OpenSim.Grid.GridServer.exe&lt;br /&gt;
 OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Linux&amp;lt;/u&amp;gt;'''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.Grid.UserServer.exe&lt;br /&gt;
 mono OpenSim.Grid.GridServer.exe&lt;br /&gt;
 mono OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 mono OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 mono OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;OSX&amp;lt;/u&amp;gt;''''&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.Grid.UserServer.exe&lt;br /&gt;
 mono OpenSim.Grid.GridServer.exe&lt;br /&gt;
 mono OpenSim.Grid.AssetServer.exe&lt;br /&gt;
 mono OpenSim.Grid.InventoryServer.exe&lt;br /&gt;
 mono OpenSim.Grid.MessagingServer.exe&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
Connect: opensim://myipaddress:9000&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/User_Documentation</id>
		<title>User Documentation</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User_Documentation"/>
				<updated>2008-10-07T19:03:22Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Initial Setup */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Template:Quicklinks}}&lt;br /&gt;
__NOTOC__&lt;br /&gt;
==Initial Setup==&lt;br /&gt;
* [[Download]] - Download instructions&lt;br /&gt;
* [[Build Instructions]] - How to build and compile OpenSim from Source&lt;br /&gt;
* [[Configuration]] - How to get your OpenSim server up and running&lt;br /&gt;
* [[Connecting]] - How to connect a compatible viewer to OpenSim&lt;br /&gt;
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.&lt;br /&gt;
* [[Tips]] - Useful tips from users like you&lt;br /&gt;
* [[FAQ]] - Frequently Asked Questions&lt;br /&gt;
&lt;br /&gt;
==Administrator Guide==&lt;br /&gt;
* [[Server Commands]] - Commands to control OpenSim&lt;br /&gt;
* [[OpenSim Database support]] - Dealing with databases&lt;br /&gt;
* [[Logging]] - Logging in OpenSim&lt;br /&gt;
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server&lt;br /&gt;
* [[Automating Tasks]] - How to make administrating a walk in the park&lt;br /&gt;
* [[Network Settings]] - NAT, Ports, Services and more...&lt;br /&gt;
* [[Management]] - All about being an effective administrator/moderator&lt;br /&gt;
* [[Performance]] - How to tweak OpenSim's performance&lt;br /&gt;
* [[Console-less OpenSim]] - How to run OpenSim without console&lt;br /&gt;
* [[GridInfo]] - how to provide information about your grid to smart clients&lt;br /&gt;
&lt;br /&gt;
==Facilities==&lt;br /&gt;
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim&lt;br /&gt;
&lt;br /&gt;
==Scripting==&lt;br /&gt;
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting&lt;br /&gt;
* [[Scripting Library]] - A list of example scripts&lt;br /&gt;
&lt;br /&gt;
==Tutorials==&lt;br /&gt;
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid&lt;br /&gt;
* [[Hints &amp;amp; Tricks]] - A page for Hints and Tricks&lt;br /&gt;
* [[Using L3DT]] - How to create custom terrains&lt;br /&gt;
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains&lt;br /&gt;
* [[Linux Gridserver]] using 'moo' - How to setup a Gridserver on a Linux machine using 'moo'&lt;br /&gt;
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu&lt;br /&gt;
* [http://www.adamfrisby.com/blog/2008/08/resources-for-running-your-own-opensim Adam's OpenSim resources blog post] - a list of resources for running OpenSim&lt;br /&gt;
* [http://rock-vacirca.blogspot.com Rock Vacirca's Blog] - lots of tutorials, not only on OpenSim, but on MySQL, Hippo, Second Inventory, etc&lt;br /&gt;
&lt;br /&gt;
==Contribution Policy==&lt;br /&gt;
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki&lt;br /&gt;
[[Category:Users]]&lt;br /&gt;
&amp;lt;cleanpage title=hide cats=hide /&amp;gt;&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Mysql-config_example</id>
		<title>Mysql-config example</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Mysql-config_example"/>
				<updated>2008-10-03T12:53:39Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt; {{obsolete}}&lt;br /&gt;
&lt;br /&gt;
 [Startup]&lt;br /&gt;
 gridmode = false&lt;br /&gt;
&lt;br /&gt;
 ; Select a mesher here. ZeroMesher is save and fast.&lt;br /&gt;
 ; ZeroMesher also means that the physics engine models the physics of prims&lt;br /&gt;
 ; sticking to the basic shapes the engine does support. Usually this is only a box.&lt;br /&gt;
 ; Meshmerizer gives a better handling of complex prims by using triangle meshes.&lt;br /&gt;
 ; Note, that only ODE physics currently deals with meshed prims in a satisfactoring way&lt;br /&gt;
 ; &lt;br /&gt;
 ;meshing = ZeroMesher&lt;br /&gt;
 meshing = Meshmerizer&lt;br /&gt;
&lt;br /&gt;
 ; Choose one of the physics engines below&lt;br /&gt;
 ;physics = basicphysics&lt;br /&gt;
 ;physics = POS&lt;br /&gt;
 physics = OpenDynamicsEngine&lt;br /&gt;
 ;physics = modified_BulletX&lt;br /&gt;
&lt;br /&gt;
 ; *** Prim Storage - only leave one storage_plugin uncommented ***&lt;br /&gt;
 ; --- The NullStorage stores nothing - effectively disabling persistence:&lt;br /&gt;
 ; storage_plugin = &amp;quot;OpenSim.Data.Null.dll&amp;quot;&lt;br /&gt;
 &lt;br /&gt;
 ; --- To use sqlite as region storage:&lt;br /&gt;
 ;storage_plugin = &amp;quot;OpenSim.Data.SQLite.dll&amp;quot;&lt;br /&gt;
 ;storage_connection_string=&amp;quot;URI=file:OpenSim.db,version=3&amp;quot;;&lt;br /&gt;
 &lt;br /&gt;
 ; --- To use MySQL storage, supply your own connectionstring (this is only an example):&lt;br /&gt;
 ;     note that the supplied account needs create privilegies if you want it to auto-create needed tables.&lt;br /&gt;
 storage_plugin=&amp;quot;OpenSim.Data.MySQL.dll&amp;quot;&lt;br /&gt;
 storage_connection_string=&amp;quot;Data Source=localhost;Database=opensim;User ID=root;Password=******;&amp;quot;;&lt;br /&gt;
&lt;br /&gt;
 startup_console_commands_file = &amp;quot;startup_commands.txt&amp;quot;&lt;br /&gt;
 shutdown_console_commands_file = &amp;quot;shutdown_commands.txt&amp;quot;&lt;br /&gt;
 serverside_object_permissions = true&lt;br /&gt;
&lt;br /&gt;
 ; Select the type of database to use for asset storage&lt;br /&gt;
 ;asset_database = &amp;quot;db4o&amp;quot;&lt;br /&gt;
 ;asset_database = &amp;quot;sqlite&amp;quot;&lt;br /&gt;
 ;asset_database = &amp;quot;grid&amp;quot;&lt;br /&gt;
 ;asset_database = &amp;quot;mssql&amp;quot;&lt;br /&gt;
 asset_database = &amp;quot;mysql&amp;quot;&lt;br /&gt;
&lt;br /&gt;
 verbose = true&lt;br /&gt;
&lt;br /&gt;
 ; ScriptEngine&lt;br /&gt;
 script_engine = OpenSim.Region.ScriptEngine.DotNetEngine.dll&lt;br /&gt;
 ;Experimental remote ScriptServer plugin:&lt;br /&gt;
 ;script_engine = OpenSim.Region.ScriptEngine.RemoteServer.dll&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ; if you would like to allow prim to be physical and move by physics with the physical checkbox in the client set this to true.&lt;br /&gt;
 physical_prim = true&lt;br /&gt;
&lt;br /&gt;
 ; To run a script every few minutes, set the script filename here&lt;br /&gt;
 ; timer_Script = &amp;quot;filename&amp;quot;&lt;br /&gt;
&lt;br /&gt;
 [StandAlone]&lt;br /&gt;
 accounts_authenticate = true&lt;br /&gt;
 welcome_message = &amp;quot;Your welcome message&amp;quot;&lt;br /&gt;
 ;inventory_plugin = &amp;quot;OpenSim.Data.SQLite.dll&amp;quot;&lt;br /&gt;
 inventory_plugin = &amp;quot;OpenSim.Data.MySQL.dll&amp;quot;&lt;br /&gt;
 ;userDatabase_plugin = &amp;quot;OpenSim.Data.SQLite.dll&amp;quot;&lt;br /&gt;
 userDatabase_plugin = &amp;quot;OpenSim.Data.MySQL.dll&amp;quot;&lt;br /&gt;
 default_location_x = 1000&lt;br /&gt;
 default_location_y = 1000&lt;br /&gt;
 dump_assets_to_file = false&lt;br /&gt;
&lt;br /&gt;
 [Network]&lt;br /&gt;
 http_listener_port = 9000&lt;br /&gt;
 remoting_listener_port = 8895&lt;br /&gt;
&lt;br /&gt;
 ; Uncomment below to enable llRemoteData/remote channels&lt;br /&gt;
 ; remoteDataPort = 20800&lt;br /&gt;
&lt;br /&gt;
 grid_server_url = &amp;quot;http://127.0.0.1:8001&amp;quot;&lt;br /&gt;
 grid_send_key = &amp;quot;null&amp;quot;&lt;br /&gt;
 grid_recv_key = &amp;quot;null&amp;quot;&lt;br /&gt;
&lt;br /&gt;
 user_server_url = &amp;quot;http://127.0.0.1:8002&amp;quot;&lt;br /&gt;
 user_send_key = &amp;quot;null&amp;quot;&lt;br /&gt;
 user_recv_key = &amp;quot;null&amp;quot;&lt;br /&gt;
&lt;br /&gt;
 asset_server_url = &amp;quot;http://127.0.0.1:8003&amp;quot;&lt;br /&gt;
 &lt;br /&gt;
 inventory_server_url = &amp;quot;http://127.0.0.1:8004&amp;quot; &lt;br /&gt;
 &lt;br /&gt;
 [Chat]&lt;br /&gt;
 whisper_distance = 10&lt;br /&gt;
 say_distance = 30&lt;br /&gt;
 shout_distance = 100&lt;br /&gt;
 &lt;br /&gt;
 ; Uncomment the following for IRC bridge&lt;br /&gt;
 ; experimental, so if it breaks... keep both parts... yada yada&lt;br /&gt;
 ; also, not good error detection when it fails&lt;br /&gt;
 ;[IRC]&lt;br /&gt;
 server  = irc.freenode.net&lt;br /&gt;
 nick    = OSbot&lt;br /&gt;
 channel = #innovatieproject &lt;br /&gt;
 &lt;br /&gt;
 ; Uncomment the following to control the progression of daytime&lt;br /&gt;
 ; in the Sim.  The defaults are what is shown below&lt;br /&gt;
 [Sun]&lt;br /&gt;
 ; number of wall clock hours for an opensim day.  24.0 would mean realtime&lt;br /&gt;
 day_length = 0.5 &lt;br /&gt;
 &lt;br /&gt;
 ; send a Sun update ever frame_rate # of frames.  A lower number will&lt;br /&gt;
 ; make for smoother sun transition at the cost of network&lt;br /&gt;
 ;frame_rate = 100&lt;br /&gt;
[[Category:Configuration]]&lt;br /&gt;
[[Category:Users]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/User:MoHax</id>
		<title>User:MoHax</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/User:MoHax"/>
				<updated>2008-05-12T01:49:07Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: New page: [http://imohax.com http://imohax.com]&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[http://imohax.com http://imohax.com]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Development_Team</id>
		<title>Development Team</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Development_Team"/>
				<updated>2008-05-12T01:47:42Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Additional Developers/Testers/Contributors */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== OpenSim Core Developers ==&lt;br /&gt;
These people have commit access to our central SVN server and are regular contributors to the codebase.&lt;br /&gt;
&lt;br /&gt;
(please add in as much info as you like for your name)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;table border=&amp;quot;1&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;0&amp;quot; class=&amp;quot;sortable&amp;quot;&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Photo &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;IRC Nick &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Name&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;SL Avatar&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Other Grid&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Time Zone&amp;lt;br&amp;gt;(UTC)&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Org&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Areas of Interest&amp;lt;/th&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:MW / Michael Wright |MW / Michael Wright ]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darren&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Wright Juran&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tribal Media AB&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;everything&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Adam Frisby|Adam Frisby]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Frisby&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Zaius&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;DeepThink Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Terrain, Performance&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:MingChen|MingChen]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike/Michael Ortman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ming Chen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6 (-5 in Summer)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;DeepThink Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Estate/Parcel Support/Modules/Keeping things all neat and tidy.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:lbsa71|lbsa71]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Stefan Andersson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PierreJoseph Proudhon&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;OSG:Stefan Andersson&amp;lt;br/&amp;gt;OLG:Stefan Andersson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tribal Media AB&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; 3D and Web Integration&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:SeanDague|sdague]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sean Dague&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Neas Bade&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Database, Linux, Testing, Misc&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:babblefrog|babblefrog]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Brian McBee&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dogen Coldstream&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Babblefrog Ballistic (osgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Disorganized&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Tedd|Tedd]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Hansen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Maa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Hansen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Programming/Scripting/Architecture&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:danx0r|danx0r]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dan Miller&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Albert Pascal&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;squiggle.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PHEEZIKS; everything&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:dalien|dalien]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dalien Talbot&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dalien Talbot&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mostly TCP-based&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Small fixes; rev.eng./prototyping; nightlies; git-keeper &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tleiades&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tleiades&amp;amp;nbsp;Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid servers/Database&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ckrinke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charles&amp;amp;nbsp;Krinke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charlesk&amp;amp;nbsp;Bing&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Reliability/Grid servers/ll-functions&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:chi11ken|chi11ken]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jeff Ames&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Chillken Proto&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Darok|Darok]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darok Kaminski&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics engines (especially BulletX)&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:adjohn|adjohn]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Johnson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Zeuz Zenovka&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:joha1|joha1]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Johan Berntsson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Joppi Brandenburg&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Performance, packet handling/libSL&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Teravus|Teravus]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Teravus&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Teravus Ousley&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;W3z&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics &amp;amp; Admin tools, A working sim.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Justincc|Justincc]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Justin Clark-Casey&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Lulworth Beaumont&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Justin Clark-Casey (osgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, performance &amp;amp; reliability, inventory (avatar and object), assets, scenes.&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[Alondria]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Alondria LeFay&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Alondria LeFay (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Independent&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Implementation of LSL functions and other scripting tidbits.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Additional Developers/Testers/Contributors ==&lt;br /&gt;
These people have contributed bug reports, patches or other contributions to OpenSim.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;table border=&amp;quot;1&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;0&amp;quot; class=&amp;quot;wikitable sortable&amp;quot;&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;IRC Nick &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Name&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;SL Avatar&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Other Grid&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Time Zone&amp;lt;br&amp;gt;(UTC)&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Org&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Areas of Interest&amp;lt;/th&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nebadon|Nebadon]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Michael Cerquoni&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nebadon Izumi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nebadon Izumi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-7 Arizona&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Oni Kenkon Creations&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Building, Scripting, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:jtclark48|jclark4]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jay Clark&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jay Clarke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics, Grid Host, AI, Scripting, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gareth&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:AdamStevenson|BigFootAg]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Stevenson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adamus Petrov&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Texas A&amp;amp;M University&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AI, Skynet, Evolving Systems, Biology&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Vicero Lambert|Vicero Lambert]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ldvoipeng&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;idoru&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;simsim&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Magi|Magi]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andy Agnew&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Magi Merlin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Spun Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3D Web Integration, Database stuff and playing with the odds and ends box.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;john_&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;John&amp;amp;nbsp;Moyer&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;VAJohn&amp;amp;nbsp;GeekSquad or&amp;amp;nbsp;Matthew&amp;amp;nbsp;Kendal&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Best&amp;amp;nbsp;Buy/Geek&amp;amp;nbsp;Squad&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tester&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:ClarkZone|ClarkZone]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Admin(@ClarkZone)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Childs&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Admin (ClarkZone)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Http://clarkzone.dyndns.org&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tester and Grid Host&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:aiaustin|aiaustin]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai Austin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai&amp;amp;nbsp;Austin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai&amp;amp;nbsp;AIAI&amp;amp;nbsp;(AIAI Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AIAI,&amp;amp;nbsp;University&amp;amp;nbsp;of&amp;amp;nbsp;Edinburgh&amp;lt;br&amp;gt;http://www.aiai.ed.ac.uk/~ai/&amp;lt;br&amp;gt;http://vue.ed.ac.uk/openvue/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Windows Vista tests&amp;lt;br&amp;gt;Content testing&amp;lt;br&amp;gt;Use of multiple VWs&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:balthazar|balthazar]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Trevor Brooks&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Balthazar Sin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Terrains, testing and some small coding tasks&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:jimbo2120|jimbo2120]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Michael Osias&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Illuminous Beltran&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, AI, Skynet, coding and testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Sakai|Sakai]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Steve S&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sakai Openlife (OpenlifeGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.openlifegrid.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Hardware, Testing, Contribution&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ZeroPoint&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Guilderoy&amp;amp;nbsp;Dench&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Programming/Database&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;MaltosSosa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa&amp;lt;br&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa (Central Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Central Grid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid Operator, Central Grid Project Manager. Anything we can offer, just ask.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:DerekTang|DerekTang]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Tang&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Timeless&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Tang (ChineseGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://ChineseGrid.net&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSim communities. In construction...&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:TayB|TayB]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Earl B&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Taylor Boyau&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ViziGrid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid Host,Networking,Contributions &amp;amp; Testing.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:JamieDav|JamieDav]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jamie David&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jamie David&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+7&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Forum&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Sim, Avitar, Functionality&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Krtaylor|Krtaylor]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kurt Taylor&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kurt Stringer &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Networking, Monitoring, Scripting, Inventory, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nink|Nink]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Peter Finn&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nink Noonan&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Disruptive Influence.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Bruce|Bruce]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bruce Meerson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bruce Meerson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;HiPiHi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Watching.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Darb|Darb]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Brian B. Quinn&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darb Dabney&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;regions&amp;lt;br /&amp;gt;near Berkeley&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;City of Berkeley, CA&amp;lt;br /&amp;gt; http://blog.simgis.org&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing large standalones, real-world terrain, &amp;lt;br /&amp;gt;pursuit of civic paraverses &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[CharlieO]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dan&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charlie Omega&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;oobscure&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Opensource Obscure&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.opensim.it&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;pitman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike Pitman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Rez Tone&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;cmu&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Christopher Mumme&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Snook Destiny&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.cmu-develop.de/ and research group &amp;quot;Collaboration Systems and CSCW&amp;quot; at Clausthal University of Technology&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing OpenSim, translating the OpenSim Wiki into German and reporting on OpenSim&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[Silpol]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andriy Tymchenko&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andy Tir&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;EET (+2/3)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; http://silpol.blogspot.com/ (also visible at Nokia)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Grumly|Grumly]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Forest Klaar&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grumly TheBear&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;.NET MCAD Dev/Arch/Trainer http://www.devoteam.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Trying to get into OpenSim code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[daTwitch]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;James G. Stallings II&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;br&amp;gt;Lazarus Longstaff&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Hiro Protagonist (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;House Husband&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;OSGrid Region owner, OSGrid Operator,&amp;lt;BR&amp;gt;Forum Admin, sometime wiki editor&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;gryc&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Ueusp&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Uriza&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Uriza(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PHP scripting, web interfaces, interconnectivity, cross-platformedness&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Phrearch|Phrearch]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jeroen van Veen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Phrearch Miles&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Phrearch Miles(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Amsterdam/Paris&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Documentation, scripts(perl/lsl), RIA(flex) mashup, testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Burnman|Burnman]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Allen Wilkins&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Burnman Bedlam&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sid Green (United Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Boston, USA&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;United Grid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:krisbfunk|krisbfunk]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kris Bulman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;krisbfunk Vought&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Krisbfunk Nocturnal(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PE, Canada (-4)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Edactive Technologies&amp;lt;br /&amp;gt;NocturnalEye Productions&amp;lt;br /&amp;gt;UPEI&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Currently: Testing, bug reports, wiki updating, building on OSGrid&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;[[User:HashBox|HashBox]]&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Zane Ashby&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Sibariel Darkstone&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Sibariel Darkstone (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;New Zealand (+12)&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Testing, bug reports, and updating the wiki.&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Kinoc|Kinoc]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kino Coursey&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxxon Jaxxon&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxxon Kinoc (OSgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxtron Laboratories &amp;lt;br /&amp;gt; http://www.daxtron.com&amp;lt;br /&amp;gt; University of North Texas&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:trapuh|trapuh]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Pedro Ribeiro&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Vaiten Forder&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;University Student, Escola Superior de Educação de Viseu, Portugal &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:SonicViz|SonicViz]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Paul Cohen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Komuso Tokugawa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Http://sonicviz.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Mokele|mokele]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Scott Norman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mokelembembe Mokeev&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 (Southern California)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Web Developer (PHP and MySQL)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that  I can do testing on too.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:devalnor|devalnor]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Devalnor&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;M. Watkin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1 (Belgium)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Small Patch code, bug reports, and updating the wiki.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Ezekiel|Ezekiel]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ezekiel&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ezekiel Zabelin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.yosims.com &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL) &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Diva|diva]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Crista Lopes&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Diva Canto&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Diva Canto or Crista Lopes in as many grids as possible&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;UC Irvine and http://metaverseink.com &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Search, general architecture&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Buggmaster|Buggmaster]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike D&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bug Master&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.adultmetaverse.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Data/Web PHP/PERL/MySQL&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nixnerd|nixnerd]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Richmund&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dangerously Moody&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.integratedtechnologies.eu&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Cross Platform Testing, Feedback, Bug Reporting&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:MoHax|mohax]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mo Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mo Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5 Eastern&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
[[Category:Main]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Development_Team</id>
		<title>Development Team</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Development_Team"/>
				<updated>2008-05-12T01:46:48Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: /* Additional Developers/Testers/Contributors */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== OpenSim Core Developers ==&lt;br /&gt;
These people have commit access to our central SVN server and are regular contributors to the codebase.&lt;br /&gt;
&lt;br /&gt;
(please add in as much info as you like for your name)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;table border=&amp;quot;1&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;0&amp;quot; class=&amp;quot;sortable&amp;quot;&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Photo &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;IRC Nick &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Name&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;SL Avatar&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Other Grid&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Time Zone&amp;lt;br&amp;gt;(UTC)&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Org&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Areas of Interest&amp;lt;/th&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:MW / Michael Wright |MW / Michael Wright ]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darren&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Wright Juran&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tribal Media AB&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;everything&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Adam Frisby|Adam Frisby]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Frisby&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Zaius&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;DeepThink Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Terrain, Performance&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:MingChen|MingChen]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike/Michael Ortman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ming Chen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6 (-5 in Summer)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;DeepThink Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Estate/Parcel Support/Modules/Keeping things all neat and tidy.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:lbsa71|lbsa71]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Stefan Andersson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PierreJoseph Proudhon&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;OSG:Stefan Andersson&amp;lt;br/&amp;gt;OLG:Stefan Andersson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tribal Media AB&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; 3D and Web Integration&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:SeanDague|sdague]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sean Dague&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Neas Bade&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Database, Linux, Testing, Misc&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:babblefrog|babblefrog]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Brian McBee&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dogen Coldstream&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Babblefrog Ballistic (osgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Disorganized&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Tedd|Tedd]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Hansen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Maa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tedd Hansen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Programming/Scripting/Architecture&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:danx0r|danx0r]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dan Miller&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Albert Pascal&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;squiggle.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PHEEZIKS; everything&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:dalien|dalien]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dalien Talbot&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dalien Talbot&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mostly TCP-based&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Small fixes; rev.eng./prototyping; nightlies; git-keeper &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tleiades&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tleiades&amp;amp;nbsp;Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid servers/Database&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ckrinke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charles&amp;amp;nbsp;Krinke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charlesk&amp;amp;nbsp;Bing&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Reliability/Grid servers/ll-functions&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:chi11ken|chi11ken]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jeff Ames&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Chillken Proto&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Darok|Darok]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darok Kaminski&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics engines (especially BulletX)&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:adjohn|adjohn]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Johnson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Zeuz Zenovka&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:joha1|joha1]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Johan Berntsson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Joppi Brandenburg&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3Di&amp;lt;br&amp;gt;http://www.3di.jp/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Performance, packet handling/libSL&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Teravus|Teravus]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Teravus&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Teravus Ousley&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;W3z&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics &amp;amp; Admin tools, A working sim.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Justincc|Justincc]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Justin Clark-Casey&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Lulworth Beaumont&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Justin Clark-Casey (osgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, performance &amp;amp; reliability, inventory (avatar and object), assets, scenes.&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td /&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[Alondria]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Alondria LeFay&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Alondria LeFay (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Independent&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Implementation of LSL functions and other scripting tidbits.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Additional Developers/Testers/Contributors ==&lt;br /&gt;
These people have contributed bug reports, patches or other contributions to OpenSim.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;table border=&amp;quot;1&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;0&amp;quot; class=&amp;quot;wikitable sortable&amp;quot;&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;IRC Nick &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Name&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;SL Avatar&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Other Grid&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Time Zone&amp;lt;br&amp;gt;(UTC)&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Org&amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;th&amp;gt;Areas of Interest&amp;lt;/th&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nebadon|Nebadon]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Michael Cerquoni&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nebadon Izumi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nebadon Izumi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-7 Arizona&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Oni Kenkon Creations&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Building, Scripting, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:jtclark48|jclark4]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jay Clark&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jay Clarke&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Physics, Grid Host, AI, Scripting, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gareth&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:AdamStevenson|BigFootAg]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adam Stevenson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Adamus Petrov&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Texas A&amp;amp;M University&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AI, Skynet, Evolving Systems, Biology&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Vicero Lambert|Vicero Lambert]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ldvoipeng&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;idoru&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;simsim&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Magi|Magi]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andy Agnew&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Magi Merlin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Spun Pty Ltd&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;3D Web Integration, Database stuff and playing with the odds and ends box.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;john_&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;John&amp;amp;nbsp;Moyer&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;VAJohn&amp;amp;nbsp;GeekSquad or&amp;amp;nbsp;Matthew&amp;amp;nbsp;Kendal&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Best&amp;amp;nbsp;Buy/Geek&amp;amp;nbsp;Squad&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tester&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:ClarkZone|ClarkZone]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Admin(@ClarkZone)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Childs&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Troy Admin (ClarkZone)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Http://clarkzone.dyndns.org&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Tester and Grid Host&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:aiaustin|aiaustin]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai Austin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai&amp;amp;nbsp;Austin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ai&amp;amp;nbsp;AIAI&amp;amp;nbsp;(AIAI Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+0&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AIAI,&amp;amp;nbsp;University&amp;amp;nbsp;of&amp;amp;nbsp;Edinburgh&amp;lt;br&amp;gt;http://www.aiai.ed.ac.uk/~ai/&amp;lt;br&amp;gt;http://vue.ed.ac.uk/openvue/&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Windows Vista tests&amp;lt;br&amp;gt;Content testing&amp;lt;br&amp;gt;Use of multiple VWs&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:balthazar|balthazar]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Trevor Brooks&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Balthazar Sin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Terrains, testing and some small coding tasks&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:jimbo2120|jimbo2120]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Michael Osias&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Illuminous Beltran&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, AI, Skynet, coding and testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Sakai|Sakai]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Steve S&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sakai Openlife (OpenlifeGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.openlifegrid.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Hardware, Testing, Contribution&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ZeroPoint&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Guilderoy&amp;amp;nbsp;Dench&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Programming/Database&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;MaltosSosa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa&amp;lt;br&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Maltos Sosa (Central Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Central Grid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid Operator, Central Grid Project Manager. Anything we can offer, just ask.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:DerekTang|DerekTang]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Tang&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Timeless&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Derek Tang (ChineseGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://ChineseGrid.net&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Running a public WINDOWS sim for testing, Docs, Helping Chinese users to enjoy OpenSim; building Chinese OpenSim communities. In construction...&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:TayB|TayB]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Earl B&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Taylor Boyau&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-10&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;ViziGrid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid Host,Networking,Contributions &amp;amp; Testing.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:JamieDav|JamieDav]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jamie David&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jamie David&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+7&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Forum&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Sim, Avitar, Functionality&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Krtaylor|Krtaylor]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kurt Taylor&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kurt Stringer &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Networking, Monitoring, Scripting, Inventory, Testing&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nink|Nink]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Peter Finn&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Nink Noonan&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Disruptive Influence.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Bruce|Bruce]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bruce Meerson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bruce Meerson&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;HiPiHi&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Watching.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Darb|Darb]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Brian B. Quinn&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Darb Dabney&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;regions&amp;lt;br /&amp;gt;near Berkeley&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;City of Berkeley, CA&amp;lt;br /&amp;gt; http://blog.simgis.org&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing large standalones, real-world terrain, &amp;lt;br /&amp;gt;pursuit of civic paraverses &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[CharlieO]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dan&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Charlie Omega&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mild coding/tweaking/simple feature adds, Stress testing/break stuff, Testing limits of existing code. Making sure [[LSL Status]] is up to date&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;oobscure&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Opensource Obscure&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.opensim.it&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Running a public Linux sim for testing, Docs, Helping italian users, Building opensim communities, Watching&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;pitman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike Pitman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Rez Tone&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;amp;nbsp;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Scientific visualization schemes, virt world product design, persistant workspaces, virt world based big biz&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;cmu&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Christopher Mumme&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Snook Destiny&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.cmu-develop.de/ and research group &amp;quot;Collaboration Systems and CSCW&amp;quot; at Clausthal University of Technology&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing OpenSim, translating the OpenSim Wiki into German and reporting on OpenSim&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[Silpol]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andriy Tymchenko&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Andy Tir&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;EET (+2/3)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt; http://silpol.blogspot.com/ (also visible at Nokia)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;highly uncoordinated mess with elements of palace games, under-table diplomacy, rebellion, coup d'état and mutiny. optionally pirate&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Grumly|Grumly]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Forest Klaar&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grumly TheBear&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT+1&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;.NET MCAD Dev/Arch/Trainer http://www.devoteam.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Trying to get into OpenSim code for now. Particularly interrested in data persistence. blog (Hello, Avatar!): http://lslblog.free.fr&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[daTwitch]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;James G. Stallings II&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;br&amp;gt;Lazarus Longstaff&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Hiro Protagonist (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;House Husband&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;OSGrid Region owner, OSGrid Operator,&amp;lt;BR&amp;gt;Forum Admin, sometime wiki editor&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;gryc&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Ueusp&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Uriza&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Gryc Uriza(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PHP scripting, web interfaces, interconnectivity, cross-platformedness&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Phrearch|Phrearch]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Jeroen van Veen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Phrearch Miles&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Phrearch Miles(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Amsterdam/Paris&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Documentation, scripts(perl/lsl), RIA(flex) mashup, testing&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Burnman|Burnman]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Allen Wilkins&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Burnman Bedlam&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Sid Green (United Grid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Boston, USA&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;United Grid&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, testing, and more testing! Getting familiar with the source, interested in all aspects of the project.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:krisbfunk|krisbfunk]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kris Bulman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;krisbfunk Vought&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Krisbfunk Nocturnal(OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;PE, Canada (-4)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Edactive Technologies&amp;lt;br /&amp;gt;NocturnalEye Productions&amp;lt;br /&amp;gt;UPEI&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Currently: Testing, bug reports, wiki updating, building on OSGrid&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;[[User:HashBox|HashBox]]&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Zane Ashby&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Sibariel Darkstone&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Sibariel Darkstone (OSGrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;New Zealand (+12)&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;td&amp;gt;Testing, bug reports, and updating the wiki.&amp;lt;/td&amp;gt;&lt;br /&gt;
&amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Kinoc|Kinoc]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Kino Coursey&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxxon Jaxxon&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxxon Kinoc (OSgrid)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-6&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Daxtron Laboratories &amp;lt;br /&amp;gt; http://www.daxtron.com&amp;lt;br /&amp;gt; University of North Texas&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;AI, Semantic web, Ontologies, Natural Laanguage Processing, Cyc, Bots, NPC &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:trapuh|trapuh]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Pedro Ribeiro&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Vaiten Forder&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;University Student, Escola Superior de Educação de Viseu, Portugal &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, eventual bug reports and wiki. Music, web/digital arts and php+sql.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:SonicViz|SonicViz]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Paul Cohen&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Komuso Tokugawa&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+9&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Http://sonicviz.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Audio/Music, Interactive Music, Control Protocols, Interfaces, VisualFX, Procedural animation/Generative systems + testing and general dev&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Mokele|mokele]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Scott Norman&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mokelembembe Mokeev&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 (Southern California)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Web Developer (PHP and MySQL)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Interested in seeing running on PowerPC Macs which it is. So, when I can, I'll compile and test on PowerPC Mac (PowerBook G4) and submit reports and then update the wiki if need on installing on Mac. Also have a Ubuntu 7.10 server that  I can do testing on too.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:devalnor|devalnor]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Devalnor&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;M. Watkin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1 (Belgium)&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Small Patch code, bug reports, and updating the wiki.&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Ezekiel|Ezekiel]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ezekiel&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Ezekiel Zabelin&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;+1 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.yosims.com &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Concepts, business aspects of virtual worlds - web developer (PHP, MySQL, Javascript, LSL) &amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Diva|diva]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Crista Lopes&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Diva Canto&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Diva Canto or Crista Lopes in as many grids as possible&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;UC Irvine and http://metaverseink.com &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Search, general architecture&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Buggmaster|Buggmaster]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mike D&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Bug Master&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-8 &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.adultmetaverse.com&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Grid, Data/Web PHP/PERL/MySQL&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Nixnerd|nixnerd]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Richmund&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Dangerously Moody&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;None&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;GMT &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;http://www.integratedtechnologies.eu&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Cross Platform Testing, Feedback, Bug Reporting&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;tr&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;[[User:Mohax|mohax]]&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mo Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Mo Hax&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;-5 Eastern&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;IBM&amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;td&amp;gt;Testing, Feedback, Content Contributions, Bug Reporting, Documenting, Development&amp;lt;/td&amp;gt;&lt;br /&gt;
 &amp;lt;/tr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
[[Category:Main]]&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	<entry>
		<id>http://opensimulator.org/wiki/Build_Instructions</id>
		<title>Build Instructions</title>
		<link rel="alternate" type="text/html" href="http://opensimulator.org/wiki/Build_Instructions"/>
				<updated>2008-04-24T14:48:22Z</updated>
		
		<summary type="html">&lt;p&gt;MoHax: Added build steps for RedHat&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:Users]]&lt;br /&gt;
=Installing from source=&lt;br /&gt;
&lt;br /&gt;
==Download from SVN==&lt;br /&gt;
Check out the [[Download]] Section&lt;br /&gt;
&lt;br /&gt;
==MS Windows==&lt;br /&gt;
&lt;br /&gt;
OpenSim requires either the .Net framework version 2.0, or the latest Mono. It supports the following compilers:&lt;br /&gt;
* [http://msdn2.microsoft.com/en-us/express/aa700756.aspx Microsoft Visual C# Express Edition] (note: not Visual C++)&lt;br /&gt;
* [http://www.mono-project.com/ mono]&lt;br /&gt;
&lt;br /&gt;
Note for people who just downloaded the sources from http://dist.opensimulator.org/ (the &amp;quot;Downloads&amp;quot; link on the left) be advised that some important things are missing (like MySQL template scripts). For such features, you must download using svn!&lt;br /&gt;
&lt;br /&gt;
=== Building ===&lt;br /&gt;
&lt;br /&gt;
* In the top-level directory, run the '&amp;lt;tt&amp;gt;runprebuild.bat&amp;lt;/tt&amp;gt;' file. This will create both a VS2005 solution file, and a nant build file.&lt;br /&gt;
* Open the resulting sln file with visual studio, and build it there, or if you prefer to use nant, run nant in the same top-level directory. This will build the executables.&lt;br /&gt;
&lt;br /&gt;
If you don't care about physics (walking on prims, etc), ignore the rest of this section.&lt;br /&gt;
&lt;br /&gt;
==== Physics ====&lt;br /&gt;
&lt;br /&gt;
===== Open Dynamics Engine (ODE) =====&lt;br /&gt;
If you want to implement collision-based physics, OpenDynamicsEngine (ODE) is the furthest along at the moment (9/07).  It is not fully supported, but is starting to work somewhat reliably using a small number of regions per sim.&lt;br /&gt;
&lt;br /&gt;
As installed from svn, ODE does not work on all platforms.  If you get an ODE-related crash, and/or an &amp;lt;i&amp;gt;ode.dll not found&amp;lt;/i&amp;gt; type of error (which can occur even though the dll is present!), try to build ode from source, follow the directions on [[PhysicsEngines]].&lt;br /&gt;
&lt;br /&gt;
Be sure you don't already have a system library version of libode.so that's being used instead of the one in the bin folder of your opensimulator distribution&lt;br /&gt;
&lt;br /&gt;
=== Running ===&lt;br /&gt;
&lt;br /&gt;
Recent versions of OpenSim come without an &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file. Copy the &amp;lt;tt&amp;gt;OpenSim.ini.example&amp;lt;/tt&amp;gt; file to &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; before making any changes.&lt;br /&gt;
&lt;br /&gt;
Double-click on the &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; executable file in the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory. This will start up OpenSim in standalone mode.&lt;br /&gt;
&lt;br /&gt;
The debugger in VS2005 C# may be used to step through the code. For those that use a Cygwin shell, you may find that one or more dll's have permissions that cause problems running. Most find that a &amp;quot;&amp;lt;tt&amp;gt;chmod 777 *&amp;lt;/tt&amp;gt;&amp;quot; from the &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt; directory solves this.&lt;br /&gt;
&lt;br /&gt;
Physics can be invoked by adding the appropriate line to the [Startup] section of &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt;.  For ODE, that would be:&lt;br /&gt;
&lt;br /&gt;
 physics = OpenDynamicsEngine&lt;br /&gt;
&lt;br /&gt;
You can also add a command line option to a shortcut, or run from a command prompt with:&lt;br /&gt;
&lt;br /&gt;
 -physics=OpenDynamicsEngine&lt;br /&gt;
&lt;br /&gt;
'''''Windows Vista'''''&lt;br /&gt;
&lt;br /&gt;
To run on Windows Vista, you must first disable Windows Firewall.  Under the new &amp;quot;Start&amp;quot; button of Vista, select &amp;quot;Control panel&amp;quot;.  Then double-click &amp;quot;Windows Firewall&amp;quot;.  In the window that pops up, on the left column, select &amp;quot;Turn Windows Firewall on or off&amp;quot;.  You will have to give permission for this to run, then select the option &amp;quot;Off (not recommended)&amp;quot;.  Click &amp;quot;OK&amp;quot; and exit from the Windows Firewall window.&lt;br /&gt;
&lt;br /&gt;
If you have McAfee SecurityCenter, see the description below.&lt;br /&gt;
&lt;br /&gt;
Once all the security features are disabled, right click on &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; and select &amp;quot;Run as administrator&amp;quot;.  This will pop up a window asking permission, select &amp;quot;Allow&amp;quot;.  Your OpenSim server should run in a DOS-like window and accept connections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''''McAfee Security'''''&lt;br /&gt;
&lt;br /&gt;
McAfee Security does not allow applications to listen on ports not explicitly specified.  You have two options: 1) disable firewall protection all together, 2) enable &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; to be able to open ports.&lt;br /&gt;
&lt;br /&gt;
''Disable firewall''&lt;br /&gt;
&lt;br /&gt;
Open McAfee SecurityCenter.  Select &amp;quot;Internet &amp;amp; Network&amp;quot;.  In the lower left corner is a small link to &amp;quot;Configure...&amp;quot;.  Select this.  In the right side of the window, select the bar that says &amp;quot;Firewall protection is enabled&amp;quot;.  Here you can select &amp;quot;Off&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
''Enable &amp;lt;tt&amp;gt;OpenSim.exe&amp;lt;/tt&amp;gt; to open ports''&lt;br /&gt;
&lt;br /&gt;
Open McAfee SecurityCenter.  Select &amp;quot;Internet &amp;amp; Network&amp;quot;.  In the lower left corner is a small link to &amp;quot;Configure...&amp;quot;.  Select this.  In the right side of the window, select the bar that says &amp;quot;Firewall protection is enabled&amp;quot;.  Select the &amp;quot;Advanced...&amp;quot; button.  This will pop up a new window.&lt;br /&gt;
&lt;br /&gt;
In the new window, on the left side, select &amp;quot;Program Permissions.&amp;quot;  In the middle on the right side of the window, select the &amp;quot;Add Allowed Program&amp;quot; button.  Use the browser that pops up to find the OpenSim executable and select it.&lt;br /&gt;
&lt;br /&gt;
Finally, select &amp;quot;OK&amp;quot; and exit the McAfee SecurityCenter window.&lt;br /&gt;
&lt;br /&gt;
==Linux/Mac OS X/FreeBSD==&lt;br /&gt;
&lt;br /&gt;
Please note that the current (as of 2007-11-23) SVN will not work on 64bit linux systems when built. You will need to use the binary build further down the page.&lt;br /&gt;
[[Installing and running on x86-64]]&lt;br /&gt;
&lt;br /&gt;
===Building===&lt;br /&gt;
&lt;br /&gt;
Steps to get packages that are needed to compile the source.&lt;br /&gt;
&lt;br /&gt;
'''FreeBSD 6.2'''&lt;br /&gt;
 su&lt;br /&gt;
 cd /usr/ports/devel/subversion/ &amp;amp;&amp;amp; make install clean (you may also need to rebuild apr-svn if this step fails)&lt;br /&gt;
 cd /usr/ports/lang/mono/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/devel/nant/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/databases/sqlite3/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/x11-toolkits/libgdiplus/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /opensim/installation/directory/&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
 Note: [http://opensimulator.org/wiki/OpenSim:FAQ#System.DllNotFoundException:_..2Flibopenjpeg-libsl-2.1.2.0.so|Follow the instructions on the FAQ to fix the]&lt;br /&gt;
 &amp;quot;System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so&amp;quot; issue, but use &amp;quot;gmake&amp;quot; instead of &amp;quot;make&amp;quot;&lt;br /&gt;
&lt;br /&gt;
For ODE Physics you must do the following:&lt;br /&gt;
 cd /usr/ports/graphics/libGL/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /usr/ports/graphics/libGLU/ &amp;amp;&amp;amp; make install clean&lt;br /&gt;
 cd /opensim/installation/directory/&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim-libs/trunk opensim-libs&lt;br /&gt;
 cd opensim-libs/unmanaged/OpenDynamicsEngine2/&lt;br /&gt;
 sh autogen.sh&lt;br /&gt;
 ./configure --enable-shared --enable-release --disable-demos&lt;br /&gt;
 make&lt;br /&gt;
 mv ./ode/src/libode.so /opensim/installation/directory/opensim/bin/&lt;br /&gt;
&lt;br /&gt;
'''Ubuntu 7.10'''&lt;br /&gt;
 sudo aptitude install subversion nant mono mono-gmcs libmono-microsoft8.0-cil libmono-system-runtime2.0-cil&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
* The above steps are  for just running OpenSim. If you want to use MySQL either install during the installation process or install later. For development you'll need to install gcc, gc++, and whatever other modules are needed. &lt;br /&gt;
* The  above steps work on running OpenSim 0.4 on Ubuntu Server 7.10. I  did a new install and everything worked fine for  me. During the installation process I had Ubuntu install MySQL. --[[User:Mokele|Mokele]] 11:41, 9 February 2008 (PST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''openSUSE 10.3'''&lt;br /&gt;
&lt;br /&gt;
Install an openSUSE 10.3 with its default options, add the online repositories&lt;br /&gt;
when finished installing do an online update with all the latest packages.&lt;br /&gt;
&lt;br /&gt;
In yast install these packages, for running Opensim in standalone mode.&lt;br /&gt;
 subversion (1.4.4)&lt;br /&gt;
 nant (0.85)&lt;br /&gt;
 mono-jscript&lt;br /&gt;
 - check that mono-core is installed&lt;br /&gt;
&lt;br /&gt;
* optional mysql - for Opensim running in Grid mode:&lt;br /&gt;
Install these mysql packages via yast&lt;br /&gt;
  mysql&lt;br /&gt;
  mysql-client&lt;br /&gt;
  mysql-administrator&lt;br /&gt;
  mysql-gui-tools&lt;br /&gt;
  mysql-query-browser&lt;br /&gt;
&lt;br /&gt;
Before building create the mysql database.&lt;br /&gt;
 /etc/init.d/mysql start&lt;br /&gt;
 mysql -u root -p -h localhost&lt;br /&gt;
 (when asked for password just hit enter)&lt;br /&gt;
&lt;br /&gt;
 mysql&amp;gt; create database opensim;&lt;br /&gt;
 mysql&amp;gt; quit&lt;br /&gt;
&lt;br /&gt;
set the configuration in bin/mysql_connection.ini&lt;br /&gt;
&lt;br /&gt;
Build after installation of above in bash terminal.&lt;br /&gt;
&lt;br /&gt;
 su -&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
After this you should be able to continue on starting the diffrent Servers, look in the mysql-config section.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Mac OS X 10.5/10.4'''&lt;br /&gt;
* OpenSim is now working on PowerPC Macs! Thanks to DrScofield and those who helped him. Current nightly builds for PowerPC are not working, not sure about Intel so use the 0.5 Build. OpenSim works on Intel Macs. I'm testing on PowerBook G4. Tested these step on 10.5, but not 10.4 but should work --[[User:Mokele|Mokele]] 22:36, 14 February 2008 (PST)&lt;br /&gt;
* Install XCode Developers Tools from DVD/CD Installation Disk or download  from http://developer.apple.com/. You have to create an Apple account to access the downloads if you don't have an Apple account.&lt;br /&gt;
* Install X11 for 10.4 from the Optional Install from the DVD/CD Installation Disk. X11 for 10.5 is installed by default.&lt;br /&gt;
* Install Mono 1.2.5 from http://ftp.novell.com/pub/mono/archive/1.2.5/macos-10-universal/5/MonoFramework-1.2.5_5.macos10.novell.universal.dmg and in Terminal or X11 edit the .profile file  and add the following line:&lt;br /&gt;
 export PKG_CONFIG_PATH=&amp;quot;/Library/Frameworks/Mono.framework/Versions/1.2.5/lib/pkgconfig/:${PKG_CONFIG_PATH}&amp;quot;&lt;br /&gt;
* Compile OpenSim&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim/tags/0.5.0-release opensim&lt;br /&gt;
 cd opensim &lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
* Download and Compile libopenjpeg-libsl-2.1.2.0.dylib and libsecondlife.dll&lt;br /&gt;
* libopenjpeg-libsl-2.1.2.0.dylib:&lt;br /&gt;
 svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs&lt;br /&gt;
 cd opensim-libs/openjpeg-libsl&lt;br /&gt;
 make -f Makefile.osx&lt;br /&gt;
 cp libopenjpeg-libsl-2.1.2.0.dylib ../../opensim/bin&lt;br /&gt;
* Note: The Makefile that creates the libopenjpeg-libsl-2.1.2.0.so does not compile on PowerPC, not sure about Intel. Looks like a gcc issue with compile options.&lt;br /&gt;
&lt;br /&gt;
* libsecondlife.dll: (for PowerPC Only, see  details on this step [http://xyzzyxyzzy.net/2008/02/12/installing-opensim-on-powerpcor-of-eggs-and-virtual-worlds installing OpenSim on PowerPC…or: of eggs and virtual worlds])&lt;br /&gt;
 cd .. (back into opensim-libs)&lt;br /&gt;
 nant&lt;br /&gt;
 cp libsecondlife.dll ../../opensim/bin&lt;br /&gt;
&lt;br /&gt;
* Edit the libsecondlife.dll.config (PowerPC Only). Remove the cpu=&amp;quot;x86&amp;quot; tag in the last dllmap line.&lt;br /&gt;
&lt;br /&gt;
'''RedHat'''&lt;br /&gt;
 sudo vi /etc/yum.repos.d/mono.repo&lt;br /&gt;
&lt;br /&gt;
  [mono]&lt;br /&gt;
  name=Mono for rhel-4-i386 (stable)&lt;br /&gt;
  baseurl=http://ftp.novell.com/pub/mono/download-stable/rhel-4-i386/&lt;br /&gt;
  enabled=1&lt;br /&gt;
  gpgcheck=0&lt;br /&gt;
&lt;br /&gt;
 sudo yum install mono-complete monodoc-core nant&lt;br /&gt;
 svn co svn co http://opensimulator.org/svn/opensim/trunk opensim&lt;br /&gt;
 cd opensim&lt;br /&gt;
 ./runprebuild.sh&lt;br /&gt;
 nant&lt;br /&gt;
&lt;br /&gt;
=== Physics ===&lt;br /&gt;
If you want to implement collision-based physics, OpenDynamicsEngine (ODE) is the furthest along at the moment (9/07).  It is not fully supported, but is starting to work somewhat reliably using a small number of regions per sim.&lt;br /&gt;
&lt;br /&gt;
==== Open Dynamics Engine (ODE) ====&lt;br /&gt;
As installed from svn, ODE does not work on all platforms.  If you get an ODE-related crash, and/or a &amp;lt;i&amp;gt;libode.so not found&amp;lt;/i&amp;gt; type of error, you will need to build libode from source.&lt;br /&gt;
&lt;br /&gt;
Remove &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; from the &amp;lt;tt&amp;gt;./bin&amp;lt;/tt&amp;gt; folder.  (Note that subsequent svn updates may replace it again; best fix is to copy your built &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; to &amp;lt;tt&amp;gt;bin&amp;lt;/tt&amp;gt;).  Do NOT remove &amp;lt;tt&amp;gt;ode.net.dll&amp;lt;/tt&amp;gt;!  Download the latest source packages from http://www.ode.org/.  When compiling, make sure to use the following configure options:&lt;br /&gt;
&lt;br /&gt;
 --with-trimesh=gimpact &lt;br /&gt;
 --enable-shared&lt;br /&gt;
&lt;br /&gt;
Make sure the configure script confirms these choices, and always compile with single precision (I believe that's the default).  Try &amp;lt;code&amp;gt; make -k &amp;lt;/code&amp;gt; if you get errors relating to drawstuff, test*, or openGL.  &amp;lt;code&amp;gt; make install &amp;lt;/code&amp;gt; should put &amp;lt;tt&amp;gt;libode.so&amp;lt;/tt&amp;gt; in the proper place (usually &amp;lt;tt&amp;gt;/usr/local/lib&amp;lt;/tt&amp;gt;), and it should be seen by opensim (&amp;lt;tt&amp;gt;ode.net.dll&amp;lt;/tt&amp;gt;)&lt;br /&gt;
&lt;br /&gt;
===Running===&lt;br /&gt;
Recent versions of OpenSim come without an &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; file. Copy the &amp;lt;tt&amp;gt;OpenSim.ini.example&amp;lt;/tt&amp;gt; file to &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt; before making any changes.&lt;br /&gt;
 cd bin&lt;br /&gt;
 mono OpenSim.exe&lt;br /&gt;
&lt;br /&gt;
* To invoke ODE, add the option:&lt;br /&gt;
 -physics=OpenDynamicsEngine&lt;br /&gt;
to the &amp;lt;tt&amp;gt;mono OpenSim.exe&amp;lt;/tt&amp;gt; line&lt;br /&gt;
&lt;br /&gt;
or add &amp;lt;code&amp;gt;  physics = OpenDynamicsEngine &amp;lt;/code&amp;gt; to the [Startup] section of &amp;lt;tt&amp;gt;OpenSim.ini&amp;lt;/tt&amp;gt;.  Same deal for other physics engines, when available.&lt;br /&gt;
&lt;br /&gt;
On mono 1.2.6, some distributions may see&lt;br /&gt;
 Unhandled Exception: System.NotSupportedException: CodePage 1252 not supported&lt;br /&gt;
on startup when using mysql.  This can be resolved by installing the package libmono-i18n2.0-cil (see http://bugs.mysql.com/bug.php?id=33938).&lt;br /&gt;
&lt;br /&gt;
===Dependencies===&lt;br /&gt;
The following packages and their dependencies are required to run OpenSim on a default Debian 4 netinstall:&lt;br /&gt;
* mono&lt;br /&gt;
* libmono-corlib2.0-cil&lt;br /&gt;
* libmono-sqlite2.0-cil&lt;br /&gt;
* libmono-system-web2.0-cil&lt;br /&gt;
* libmono-microsoft8.0-cil&lt;br /&gt;
* libmono-system-runtime2.0-cil&lt;br /&gt;
[[Category:Users]]&lt;/div&gt;</summary>
		<author><name>MoHax</name></author>	</entry>

	</feed>