All the Bosh Session Cache actions are executed using additional
<body/> element attributes:
cache-id. Attribute cache stores the action performed on the Bosh
cache and the
cache-id attribute refers to the
cache element if the action attribute needs it.
cache-id is optional. There is a default cache ID (empty one) associated with the elements for which the
cache-id is not provided.
<body/> element contains the cache attribute it means that all data included in the
<body/> refer to the cache action. It is not allowed, for example to send a message in the body and have the cache action set to get. The
<body/> element with cache action get, get_al*l, *on, off, remove must be empty. The
<body/> element with actions set or add must contain data to store in the cache.
on or off - the client can switch the cache on or off at any time during the session. It is recommended, however that the client switches the cache on in the first body packet, otherwise some information from the automatic cache may be missing. The automatic cache is created from the stream of data passing the Bosh component. Therefore if the cache is switched on after the roster retrieval is completed then the roster information will be missing in the cache.
If the cache is set to off (the default value) all requests to the cache are ignored. This is to ensure backward compatibility with the original Bosh specification and to make sure that in default environment the Bosh component doesn’t consume any extra resources for cache processing and storing as the cache wouldn’t be used by the client anyway.
<body/>sent as a response from the server to the client may contain cache results for a given cache-id and it may also contain other data received by the Bosh component for the client. It may also happen that large cached data are split into a few parts and each part can be sent in a separate
<body/>element. It may usually happen for the Roster data.
<body/>element. The cache content will be divided into a smaller parts of a reasonable size and will be sent to the client in a separate
<body/>elements. It may also happen that the
<body/>element contain the cache elements as well as the new requests sent to the user like new messages or presence information.
<body/>element. The only restriction is that the cached data must be a valid XML content. The data are returned to the client in exactly the same form as they were received from the server. The set action replaces any previously stored data under this ID.
Cache ID can be any characters string. There might be some IDs reserved for a special cases, like for the Roster content. To avoid any future ID conflicts reserved ID values starts with: bosh - string.
There is a default cache ID - en empty string. Thus cache-id attribute can be omitted and then the requests refers to data stored under the default (empty) ID.
Here is a list of reserved Cache IDs:
bosh-roster - The user roster is cached in the Bosh component in exactly the same form as it was received from the core server.
The Bosh Cache might do or might not do optimizations on the roster like removing elements from the cached roster if the roster remove has been received or may just store all the roster requests and then send them all to the client.
There is a one mandatory optimization the Bosh Cache must perform. It must remember the last (and only the last) presence status for each roster item. Upon roster retrieving from the cache the Bosh component must send the roster item first and then the presence for the item. If the presence is missing it means off-line presence.
If the roster is small it can be sent to the client in a single packet but for a large roster it is recommended to split contact lists to batches of max 100 elements. The Bosh component may send all roster contacts first and then all presences or it can send a part of the roster, presences for sent items, next part of the roster, presences for next items and so on….