Difference between revisions of "Capabilities"
Jump to navigation
Jump to search
Zero Linden (talk | contribs) |
|||
| Line 22: | Line 22: | ||
Notes: | Notes: | ||
* Do not rely on the form of a capability, other than it must be http: or https:. Capabilities from the same source needn't point to the same host or port, and the path needn't start /cap. | * Do not rely on the form of a capability, other than it must be http: or https:. Capabilities from the same source needn't point to the same host or port, and the path needn't start /cap. | ||
''See also'': [http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical|Tao Takaishi's blog discussion of capabilities]] | |||
Revision as of 14:37, 9 May 2008
The viewer (and other client applications) can request capabilities from the simulators to gain access to certain features.
- Map from public URL to private URL
- Cap set <map><key>Asset upload</key>
- <uri>URI1</uri>
- <key>Seed capability</key>
- <uri>URI2</uri>
- </map>
- Viewer knows public URL
- Internally, backbone stores both public and private URL
Flow for getting capabilities
- Viewer contacts login server requesting a particular capability
- Login server contacts sim
- Sim contacts backbone, sending a private uri corresponding to an action or service
- Backbone generates and returns a public uri corresponding to the private uri
Notes:
- Do not rely on the form of a capability, other than it must be http: or https:. Capabilities from the same source needn't point to the same host or port, and the path needn't start /cap.
See also: Takaishi's blog discussion of capabilities]