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.
One of the basic goals that started research into SNOW-375 is the desire to have a shared code base, the desire to focus on a reusable model, a set of tools (such as automated quality assurance), and to integrate easily with the capabilities of more powerful and distributed "home" and workstations. We can't expect a monolithic design to reinvent solutions to all accessibility needs and match the already tried-and-proven devices, yet we can improve on how existing environments can work together.
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 & Capabilities
An organic process to standardize the resources are still underway in regards to the overall client/server architecture. SNOW-375 has taken a part in that process. VWRAP's history, even with foundations in AWG, and now IETF, has define the major roles of the architecture. The key component to resources are known as capabilities.
Instead of traditional ACLs, capabilities are a means to present available features or adapt to features not available. ACLs rely on a specific index to a predefined set of features and restrictions. Capabilities, however, allow for dynamic set of features and restrictions per connection. ACLs are usually more stateful while capabilities are more stateless. The logic behind capabilities doesn't bloom easily when the environment is still heavily based on static ACLs. One particular feature of capabilities often used is their presentation as public URIs or private URIs. Public URIs are easily directly queried while private URIs usually involve a proxy and permissions to resolve indirectly.
SNOW-375 currently uses public URIs, yet this is an implementation detail that may easily change to support private URIs.
For a dictionary of API resources, please see: All SNOW-375 Resources
Queries & Type System
LLSD is used for the payload of queries. Please see IETF VWRAP: Abstract Type System for the Transmission of Dynamic Structured Data for definitions and the LLIDL description language.
Payloads that contain nested XML structures may not work well with JSON, so only LLSD is supported. This could be resolved with JSON specific queries, yet Snowglobe would still internally have to convert LLSD to JSON, so that would be an implementation detail on the transport layer.
SNOW-375 currently differs with VWRAP's synchronization of events. SNOW-375 assumes a bidirectional flow of queries is possible, yet if a unidirectional flow is only possible then it may either fallback to VWRAP style or fail to connect. The logic of this is not obvious nor fully implemented (not enough use-cases at current version to support full unidirectional implementation). The word bidirectional here is differs from the "request/response" terminology to avoid confusion. With SNOW-375, the client also implements a server profile. There is less confusion to use specific names of domains and roles rather than simply client/server. Also, the bidirectional functionality doesn't depend on an event queue (as defined in VWRAP). Bidirectional queries may be more asynchronous than one expects from an event queue.
Due to the asynchronous abilities, multiple queries may be combined into one. The Snowglobe Viewer needs this to efficiently receive hundreds of queries in a single frame loop. The Snowglobe Viewer in return tries to wait for idle handlers to batch process queries.
Simple queries relate to single request and response type flow. Complex queries either involve combined simple queries or may involve patterns of simple and complex queries. For example, a UI event may trigger several hundred queries, which then each get automatically combined. The combined query sent to the viewer may then proxy several requests to the simulator for inventory data. That could then turn into a pattern of delayed and immediately available information. As delayed information finally arrives, it also is now being processed with several new requests to get asset data from what already was cached. Etc. These are complex combined queries because they resolve to delayed, not found, or result in other queries. Modularity in design removes most of the complexity in being able to understand these patterns. Pretty much the same concepts already found in the viewer except applied with asynchronism in mind rather than a frame-loop/long-poll.