You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or API help for more information.
<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Sirikata" />
  </query-continue>
  <query>
    <pages>
      <page pageid="36" ns="0" title="Roadmap">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">''This is the roadmap and brainstorm for development''

==Assigned Tasks==
* B scripter GUI (improvements to interface)
* B/E V8 closures (fix storage of functions in v8 to save closure as well as function text)
* E/J CDN support for music (serve music files as well as meshes)

==Ideas==

===Deployment===
* Backups of OH data

===Demo World===
* Repository for world-specific scripts (avatar script, anything we expect to be in there by default).
* Build a nice demo scene, large enough to require some exploration to see it all.
* Scripts for building into package (i.e. all the data required to support [[Sirikata URIs]]
* Get a few good, tested avatars on the CDN and get the default demo avatar to use these simple animations well

===System Features===
* Space
** Physics improvements -- get avatars on terrain working well
** Generate collision event messages for objects, maybe based on subscription request

* CDN
** Expose progressive meshes

* OH
** Progressive mesh loading
** Improve Emerson storage -- make it much easier to interface and get a persistent object
** Improve object manipulation interface (could be in deployment specific code, i.e. under Demo World)
** Object migration between OHs
** Fix closures/provide full snapshotting (timers/register handlers/etc)
** libmesh filters should not strip animations (eg. check if joints before collapsing two vertices).
** Playing multiple animations at once (blend/interpolation)
** Exposing physics collisions to Emerson.
** Fix Gui isolation
** Better OH connection failure handling
** Reduce Emerson memory usage

===Documentation===
* Storage tutorial
* Sandbox tutorial
* Getting started with demo, maybe just update getting started for users since a lot of steps can be avoided when someone provides the configuration for you.
* Simple demo videos showing how to join and interact with the world/other users.

==Long-term Goals &amp; Research==
* Add audio support (purely OH-based to support, e.g. simple sound effects and local voice chat, then consider adding mixing support to the space server).
* Load balancing objects across object hosts
* Distributed physics -- extend physics to work with objects including boundaries
* Mesh/object aggregation
* Multicast
* New transport abstractions targeted at VWs (e.g. last reliable)</rev>
        </revisions>
      </page>
      <page pageid="15" ns="0" title="Running the dev preview">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">==== Disclaimer ====

This page documents how to actually run The Sirikata Dev Preview (codename Meru) servers and clients once you've compiled the source.  Beyond some simple options that won't change, everything is controlled by the options mechanism. So if you can't find something here (or it doesn't seem to match up with your experience) your next stop should be Options.hpp and Options.cpp in the source tree.

==== Notes for All Scenarios ====

In all cases you need to start the client and server from the Meru/data/bin/ directory.  This is required so we can find all the necessary libraries and resources.

Also, some commands in here are quite long because they require specifying a lot of parameters.  You should be able to set up configuration files to save you some typing.  Just run dev preview specifying the config file on the command line and it should pull in all the options correctly, e.g.:
 
 ../../src/meru --config=server1.cfg

==== Single Server, Multiple Clients ====

This is the simplest mode to get running.  All the options default to settings appropriate for this scenario.  To run the server, simply run

 ../../src/meru --mode=server

This starts the server up with all the default subsystems (see descriptions below).

==== Multiple Servers, Multiple Clients ====

In this mode, the method for starting clients remains exactly the same, simply adjust the connection parameters for each one to connect to different servers.  Note that you can do this from the command line, e.g.:

 ../../src/meru --username=testplayer --password=testplayer --server=mytestserver --port=mytestport1


===== Server Options =====

In order to get a functional distributed server system working you need to specify distributed implementations of all the server subsystems. Below are listed the subsystems by the option name (by which you specify them on the command line) followed by the implementations.  For many, the current &quot;distributed&quot; implementation is in fact one that works with multiple servers but is centralized on yet another server.

* Account Manager (--accounts=) - sqlite, smalltable
* Proximity Manager (--proximity=) - simple, bullet, central
* Object Storage (--object-store=) - sqlite, smalltable
* Message Router (--message-router=) - local, smalltable
* Reference Registry (--reference-registry=) - sqlite, smalltable
* Object Connection Manager (--object-connections=) - simple, smalltable

You will also need to set separate listening ports for each server.

===== Centralized Utilities =====

Many of the current &quot;distributed&quot; subsystems require a centralized controller.  Currently this refers to all the smalltable implementations as well as the centralized proximity manager.  You can find these utilities in Meru/util/.  Both are python scripts that should run fine with no parameters (all the subsystem implementations are set to use the same default settings).

===== Example =====

As an example, lets say you wanted to run a two node server network.  You would need to run these commands in separate terminals:

From Meru/:
 python util/small_table.py


From Meru/:
 python util/centralized_proximity_manager.py


From Meru/data/bin:
 ../../src/server --port=8888 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable


From Meru/data/bin:
 ../../src/server --port=8889 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable


Then you could connect to localhost on ports 8888 and 8889 with the client.

===Importing meshes===
Hit the 'l' key then you can select: 

# a mesh exported from 3d studio max using our exporter http://sirikata.com/res/dev_preview/SirikataSceneExporter.zip
# a mesh from [http://www.ogre3d.org/ Ogre3D] in general (with appropriate materials, etc in the same folder)
# or pick a few example meshes by typing in a URI. For instance:
 meru://cplatz@/ArchD_Triumph_01.mesh

or
 meru://cplatz@/Plant_Big_04.mesh
or
 meru://cplatz@/Tree_Common_trop_02.mesh
in the filename field

More examples are listed at http://graphics.stanford.edu/~danielrh/dns/names/global/cp/la/cplatz/ (be sure to prefix the filename with meru://cplatz@/)</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>