Difference between revisions of "Current Sim Capabilities"
| Line 7: | Line 7: | ||
A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID | A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID | ||
In the current client, | In the current client, sim capabilities are accessed via an https request of the form: | ||
https request {POST, URL:port, path, body, header} | https request {POST, URL:port, path, body, header} | ||
| Line 23: | Line 22: | ||
:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd> | :• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd> | ||
sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result. | |||
=Sim Capabilities= | =Sim Capabilities= | ||
=Sub-Capabilities= | =Sub-Capabilities= | ||
Revision as of 03:58, 21 November 2007
Introduction
In the current protocols, there appear to be at least 2 kinds of capabilities: Sim capabilities and Sub-Capabilities obtained from the Sim Capability. The current login protocols return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new login protocols.
Accessing Capabilities
A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID
In the current client, sim capabilities are accessed via an https request of the form:
https request {POST, URL:port, path, body, header}
where
- • URL:port is of the form: sim1234.agni.lindenlab.com:12345;
- • path is of the form: /cap/UUID;
- • body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
- • Header is of the form: "content-type": "application/xml";
The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:
- • <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>
sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.