User:Dzonatas Sol/SNOW-375 Resources/Interface
| Resource | Method | Description |
| /Interface/Connect | POST | -> &connect <- &result |
| /Interface/UI | POST | -> { UI: bool } <- { status: string } |
| /Interface/Status | POST | -> { Status: string } <- { status: string } |
Note: Description syntax is only based on LLIDL.
/Interface/Connect
Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [[1]]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.
["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. For example, ray-casting may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]
Forward:
Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).
An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.
Reverse:
The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.
A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.
[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure, or 4) let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]
/Interface/Status
A message that describes the changed state of the connection.
connect
{
| (host) | : string |
| port | : integer |
}
Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.
result
{
| status | : string |
| session | : uuid |
| Version | : string |
|
Version string is only informational, as given or detected capabilities are more significant.