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 a client-side scripted communicator (Snowglobe has unintentionally only supported left-to-right user interfaces due to its organic design). It could be an overhall to internally update the monolithic program in a standalone manner. We used the scripts to 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, and it still uses the same "chat" channels.
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, distributed, "home" and workstation architecture. We can't expect a monolithic design to reinvent solutions to all accessibility needs and still match the quality of the already tried-and-proven devices (or expect anybody waste time in redundant QA), yet we can improve on how existing environments can work together.
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 another process, bidirectional between two processes, or internalized to an implementation detail. The named resources relate to URLs (used normally build a URIs) and are used to process a query method with LLSD based payloads.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 even be on the same host. In this sense, the protocol assumes a default channel through the Snowglobe client for maximum ability, yet concurrent applications 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 defined 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 logistics 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. or the decision may be made to only support stateless SSL based transports. Use-cases are under review.
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. (Note that recommendations were made to expand LLIDL to current needs. See the VWRAP mail-list for details.)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 for multi-headed clients). The word "bidirectional" as used here differs from the "request/response" terminology, so that we can 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, yet that implies a greater learning curve. Also, the bidirectional functionality doesn't depend on a (polled) event queue (as defined in VWRAP). Bidirectional queries may be more asynchronous than one expects from an event queue, and this generally means these bidirectional expectations are stateless.
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 a 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 hundred 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 hundred new requests to get asset data from what already cached. Etc. These are complex combined queries because they resolve to delayed, not found, or result in other queries and problem resolutions. Modularity in design removes most of the complexity in being able to understand these patterns. These kinds of concepts are based on systems already found in the viewer except SNOW-375 prioritizes bidirectional needs rather than a the traditional unidirectional needs (i.e. frame-loop, long-poll).
For query models in relational databases, the unidirectional needs are comparable to the 1-to-many where the client is "1" and the servers are "many". For bidirectional needs the models are comparable to many-to-many, but which many is which? It doesn't make sense and confuses people. We can fallback to the term multi-headed (i.e. X11) to understand the query models and simple abstractions from the transport layer (i.e. ReST).