MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Sirikata",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "36": {
                "pageid": 36,
                "ns": 0,
                "title": "Roadmap",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "''This is the roadmap and brainstorm for development''\n\n==Assigned Tasks==\n* B scripter GUI (improvements to interface)\n* B/E V8 closures (fix storage of functions in v8 to save closure as well as function text)\n* E/J CDN support for music (serve music files as well as meshes)\n\n==Ideas==\n\n===Deployment===\n* Backups of OH data\n\n===Demo World===\n* Repository for world-specific scripts (avatar script, anything we expect to be in there by default).\n* Build a nice demo scene, large enough to require some exploration to see it all.\n* Scripts for building into package (i.e. all the data required to support [[Sirikata URIs]]\n* Get a few good, tested avatars on the CDN and get the default demo avatar to use these simple animations well\n\n===System Features===\n* Space\n** Physics improvements -- get avatars on terrain working well\n** Generate collision event messages for objects, maybe based on subscription request\n\n* CDN\n** Expose progressive meshes\n\n* OH\n** Progressive mesh loading\n** Improve Emerson storage -- make it much easier to interface and get a persistent object\n** Improve object manipulation interface (could be in deployment specific code, i.e. under Demo World)\n** Object migration between OHs\n** Fix closures/provide full snapshotting (timers/register handlers/etc)\n** libmesh filters should not strip animations (eg. check if joints before collapsing two vertices).\n** Playing multiple animations at once (blend/interpolation)\n** Exposing physics collisions to Emerson.\n** Fix Gui isolation\n** Better OH connection failure handling\n** Reduce Emerson memory usage\n\n===Documentation===\n* Storage tutorial\n* Sandbox tutorial\n* 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.\n* Simple demo videos showing how to join and interact with the world/other users.\n\n==Long-term Goals & Research==\n* 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).\n* Load balancing objects across object hosts\n* Distributed physics -- extend physics to work with objects including boundaries\n* Mesh/object aggregation\n* Multicast\n* New transport abstractions targeted at VWs (e.g. last reliable)"
                    }
                ]
            },
            "15": {
                "pageid": 15,
                "ns": 0,
                "title": "Running the dev preview",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "==== Disclaimer ====\n\nThis 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.\n\n==== Notes for All Scenarios ====\n\nIn 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.\n\nAlso, 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.:\n \n ../../src/meru --config=server1.cfg\n\n==== Single Server, Multiple Clients ====\n\nThis is the simplest mode to get running.  All the options default to settings appropriate for this scenario.  To run the server, simply run\n\n ../../src/meru --mode=server\n\nThis starts the server up with all the default subsystems (see descriptions below).\n\n==== Multiple Servers, Multiple Clients ====\n\nIn 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.:\n\n ../../src/meru --username=testplayer --password=testplayer --server=mytestserver --port=mytestport1\n\n\n===== Server Options =====\n\nIn 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 \"distributed\" implementation is in fact one that works with multiple servers but is centralized on yet another server.\n\n* Account Manager (--accounts=) - sqlite, smalltable\n* Proximity Manager (--proximity=) - simple, bullet, central\n* Object Storage (--object-store=) - sqlite, smalltable\n* Message Router (--message-router=) - local, smalltable\n* Reference Registry (--reference-registry=) - sqlite, smalltable\n* Object Connection Manager (--object-connections=) - simple, smalltable\n\nYou will also need to set separate listening ports for each server.\n\n===== Centralized Utilities =====\n\nMany of the current \"distributed\" 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).\n\n===== Example =====\n\nAs an example, lets say you wanted to run a two node server network.  You would need to run these commands in separate terminals:\n\nFrom Meru/:\n python util/small_table.py\n\n\nFrom Meru/:\n python util/centralized_proximity_manager.py\n\n\nFrom Meru/data/bin:\n ../../src/server --port=8888 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable\n\n\nFrom Meru/data/bin:\n ../../src/server --port=8889 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable\n\n\nThen you could connect to localhost on ports 8888 and 8889 with the client.\n\n===Importing meshes===\nHit the 'l' key then you can select: \n\n# a mesh exported from 3d studio max using our exporter http://sirikata.com/res/dev_preview/SirikataSceneExporter.zip\n# a mesh from [http://www.ogre3d.org/ Ogre3D] in general (with appropriate materials, etc in the same folder)\n# or pick a few example meshes by typing in a URI. For instance:\n meru://cplatz@/ArchD_Triumph_01.mesh\n\nor\n meru://cplatz@/Plant_Big_04.mesh\nor\n meru://cplatz@/Tree_Common_trop_02.mesh\nin the filename field\n\nMore examples are listed at http://graphics.stanford.edu/~danielrh/dns/names/global/cp/la/cplatz/ (be sure to prefix the filename with meru://cplatz@/)"
                    }
                ]
            }
        }
    }
}