|
OWorld Component Architecture Design specification
|
OWorld components attempt to provide a well-supported, highly-reliable, framework in which 3D Cyberspace platform developers can implement a simple API to make their worlds available for users currently in worlds being hosted on a different 3D cyberspace platform. Starting with avatar position, scale and orientation and iterating from there, the OWorld community builds upon the architecture suggested on this page. Four key components are discussed below.
Common Schema (SQL access)
Relational databases provide data storage for mission critical applications around the globe. OWorld will take advantage of their success by storing world, artifact, and user state through a common SQL query interface to SQL-compliant databases. Update queries originating in the shared manifest are sent to the database when convenient (i.e. not detrimental to world performance), providing ideal, reliable storage services. Data can then be accessed through popular relational database data-mining tools. The OWorld community will design and implement an appropriate database schema for 3D cyberspace state storage.
Shared Manifest
High performance cyberspace servers keep current world, artifact, and user data up to date for all clients in a reliable and realtime manner. Though design and implementation has not been as organized as within the relational database community, cyberspace servers outperform relational databases for the services shared worlds rely on. The goal of the OWorld shared manifest is to build a sharing mechanism that takes advantage of the best ideas available in the worldwide cyberspace server building community. OWorld design includes features that implement the ideas of our local manifest without an adverse affect on performance.
Local Manifest
The OWorld local manifest will allow a world builder to build and test (in single user mode) a new world and debug it with meaningful messaging (in plain English (or translation to other languages)) provided during load and interaction. The local manifest communicates with the shared manifest to keep up realtime communications with other users in the world. Importantly, the local manifest also provides a queuing service for state changes when both the shared manifest and the relational database are unavailable (as when the network is unavailable temporarily).
OWorld API
The OWorld API gives proprietary (and open source) 3D cyberspace platform developers access to OWorld services (and vice versa). Users can then move freely from platform to platform by running the necessary clients (within or outside of a Web browser) and moving among worlds through portals or teleporting. The user gains the sense of a connected 3D cyberspace while the shared manifest and relational database can track the user throughout their journey (and provide assistance when necessary).The OWorld API will initially be implemented in the Meet3D Thin Client (currrently proprietary with planned open source components) and the Virtual Playground (ditto) along with any other early adopters we can convince to participate.
|
|
