Difference between revisions of "User:Dzonatas Sol/SNOW-375 Resources"
Dzonatas Sol (talk | contribs) |
Dzonatas Sol (talk | contribs) |
||
| Line 1: | Line 1: | ||
== Overview == | |||
SNOW-375 is an API to the Snowglobe code base to query reflexive information that affects Avatar, Agent, Assets, Inventory, Gestures, and other states of the client as it interacts with the virtual world. In order to enable the widest range of devices and scripts to communicate with the client, the API is language-agnostic. The flexibility of client-side scripting is a significant feature of SNOW-375. | |||
SNOW-375 allows for a multi-headed client architecture instead of a single monolithic design. There are many possibilities to this besides client-side scripting, like augmented reality devices, gesture recognition devices, social networking, advanced heads-up displays, integrated desktop programs (desklets), joysticks, machinima tools, and many more. Multi-headed clients are also significant, yet its transport layer may be platform dependent. | |||
Another significant feature of SNOW-375 is that it has enabled right-to-left (bidi glyphs) text, which means that the Second most spoken language in the world is enabled by client-side scripted communicator since Snowglobe has only supported left-to-right user interfaces. We used the scripts control toolkits that were already available to display advanced input and output methods for automatic detection of text direction and glyph shaping. This immediately opens up Second Life much larger audience than thought to already have. | |||
== Technical == | |||
SNOW-375 is based on the ReST design paradigm, so the transport layer can be fully abstracted from its default style, HTTP. Each query uses a named resource, a ReST method, and a LLSD formatted payload. Being reflexive, the flow of the query can be unidirectional to an another process, bidirectional between two processes, or internalized to an implementation. The named resources relate to a URL (to normally build a URI) used to process a query method with a payload. | |||
Resources may overlap functionality with VWRAP, yet VWRAP has not been designed for the dynamics that SNOW-375 demands. VWRAP has assumed a single headed client, yet SNOW-375 has been designed from the start to support multi-headed clients that may not be on the same host. In this sense, the protocol assumes a default channel through the Snowglobe client for maximum ability, yet concurrent application may use their own channel. HTTP Textures is an example where positional data is gathered from the Snowglobe client, yet the tiles are downloaded directly to the concurrent application instead of through the Snowglobe client. This multi-headed design allows the Snowglobe client to preform and not waste time with bandwidth it doesn't need to process. | |||
== Resources == | |||
Resources are grouped by major representations. These are still being developed, yet a basic set exists that enables communication and gesture activation. | |||
Resources may have more than one method. Each one is described. Parenthesized methods are just a more complex method of the original simpler method being described. Complex queries are usually used to group multiple queries together, yet this action is more of an implementation detail and helpful to know it exists. | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/ControlGroup|ControlGroup]] | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/Agent|Agent]] | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/Asset|Asset]] | |||
| | * [[User:Dzonatas_Sol/SNOW-375_Resources/AvatarTracker|AvatarTracker]] | ||
* [[User:Dzonatas_Sol/SNOW-375_Resources/ChatterBox|ChatterBox]] | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/GestureManager|GestureManager]] | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/Inventory|Inventory]] | |||
* [[User:Dzonatas_Sol/SNOW-375_Resources/Interface|Interface]] | |||
| | |||
| | |||
| | |||
| | |||
| | |||
| | |||
Revision as of 15:05, 30 July 2010
Overview
SNOW-375 is an API to the Snowglobe code base to query reflexive information that affects Avatar, Agent, Assets, Inventory, Gestures, and other states of the client as it interacts with the virtual world. In order to enable the widest range of devices and scripts to communicate with the client, the API is language-agnostic. The flexibility of client-side scripting is a significant feature of SNOW-375.
SNOW-375 allows for a multi-headed client architecture instead of a single monolithic design. There are many possibilities to this besides client-side scripting, like augmented reality devices, gesture recognition devices, social networking, advanced heads-up displays, integrated desktop programs (desklets), joysticks, machinima tools, and many more. Multi-headed clients are also significant, yet its transport layer may be platform dependent.
Another significant feature of SNOW-375 is that it has enabled right-to-left (bidi glyphs) text, which means that the Second most spoken language in the world is enabled by client-side scripted communicator since Snowglobe has only supported left-to-right user interfaces. We used the scripts control toolkits that were already available to display advanced input and output methods for automatic detection of text direction and glyph shaping. This immediately opens up Second Life much larger audience than thought to already have.
Technical
SNOW-375 is based on the ReST design paradigm, so the transport layer can be fully abstracted from its default style, HTTP. Each query uses a named resource, a ReST method, and a LLSD formatted payload. Being reflexive, the flow of the query can be unidirectional to an another process, bidirectional between two processes, or internalized to an implementation. The named resources relate to a URL (to normally build a URI) used to process a query method with a payload.
Resources may overlap functionality with VWRAP, yet VWRAP has not been designed for the dynamics that SNOW-375 demands. VWRAP has assumed a single headed client, yet SNOW-375 has been designed from the start to support multi-headed clients that may not be on the same host. In this sense, the protocol assumes a default channel through the Snowglobe client for maximum ability, yet concurrent application may use their own channel. HTTP Textures is an example where positional data is gathered from the Snowglobe client, yet the tiles are downloaded directly to the concurrent application instead of through the Snowglobe client. This multi-headed design allows the Snowglobe client to preform and not waste time with bandwidth it doesn't need to process.
Resources
Resources are grouped by major representations. These are still being developed, yet a basic set exists that enables communication and gesture activation.
Resources may have more than one method. Each one is described. Parenthesized methods are just a more complex method of the original simpler method being described. Complex queries are usually used to group multiple queries together, yet this action is more of an implementation detail and helpful to know it exists.