Difference between revisions of "ReadOfflineMsgs"
Jump to navigation
Jump to search
Monty Linden (talk | contribs) m |
Monty Linden (talk | contribs) m (Still documenting the past.) |
||
(One intermediate revision by the same user not shown) | |||
Line 57: | Line 57: | ||
but that should not be encountered anymore. | but that should not be encountered anymore. | ||
Side Effects. The GET operation currently deletes all of an agent's stored IMs and subsequent calls will return empty arrays until new IMs are stored. | |||
=== History === | |||
{| class="wikitable" | |||
|- | |||
| ~2018 || Introduced | |||
|} |
Latest revision as of 08:46, 1 April 2022
The ReadOfflineMsgs Capability performs a function similar to the RetrieveInstantMessages LLMessage. It retrieves offline Instant Messages and returns them to the caller. Those IMs are returned directly in the response body rather than in individual messages. As a side-effect of the retrieval, certain offers, such as friendship, may become active and available to the caller.
Client Request GET -> <empty>
; 200 Response <- [ [ { asset_id: UUID, binary_bucket: Binary, dialog: Integer, estate_id: Integer, from_agent_id: UUID, from_agent_name: String, from_group: Boolean, message: String, message_time: String, offline: Integer, parent_estate_id: Integer, position: [ Real, Real, Real ], region_id: UUID, timestamp: Integer, to_agent_id: UUID, transaction-id: UUID }, { }, ... { } ] ]
An early form of the service had a response structure of:
{ messages: [ { <IM_0> }, { <IM_1> }, ... { <IM_n> } ] }
but that should not be encountered anymore.
Side Effects. The GET operation currently deletes all of an agent's stored IMs and subsequent calls will return empty arrays until new IMs are stored.
History
~2018 | Introduced |