To invoke a sub-activity, an action uses the GOSUB task. This operates just like the normal GO task, only the user agent remembers the calling action on the activity stack. Specifically, the user agent needs to remember:
Any card within the sub-activity can either return or cancel directly back to the calling activity. When the sub-activity returns via the RETURN task, the variables specified in the RECEIVE option are set in the calling activity, and the URL in the calling action's NEXT option is fetched and displayed. If the sub-activity returns via the CANCEL task, the URL in the calling action's CANCEL option is fetched and displayed. If the NEXT or CANCEL option is not specified in the calling action, the calling card is displayed.
A sub-activity can be marked FRIEND=TRUE by the calling action. If so marked, the sub-activity can effect the state of the calling activity. A friendly sub-activity can override the NEXT and CANCEL options by specifying a DEST option in the RETURN or CANCEL task. A friendly sub-activity can also unset all the variables in the calling activity by setting the CLEAR option to TRUE in a RETURN or CANCEL task. If both the CLEAR and RETVALS options are specified, the calling activity's variables are first cleared, and then the variables in its RECEIVE option are set from the RETVALS.
If the user agent caches decks, it may continue to display cards in decks with expired TTLs under certain circumstances:
The user agent is in the process of navigating backwards when it performs a PREV, RETURN, or CANCEL task. Note, however, in the case of RETURN and CANCEL if the caller has specified a NEXT or CANCEL option (respectively), the access of the NEXT or CANCEL destination is considered to be navigating forwards, i.e. normal cache expiration checking applies.
It is acceptable for the user agent to limit the number of history entries per activity. In the case of history entry exhaustion, the user agent should delete the least-recently-used history entry.
It is acceptable for the user agent to limit the size of the activity stack. In the case of activity stack exhaustion, the user agent should delete the oldest activity.
In selecting decks to free from the cache, the user agent should refrain from freeing decks that are referenced by the activity stack. If cache space remains exhausted after freeing unreferenced entries, the user agent should delete the oldest activity in the activity stack and free any unreferenced entries in the deck cache until there is sufficient space to continue processing. However, the user agent should never delete the current entry. If cache space remains exhausted and there is only one activity on the activity stack, the least-recently-used history entry may be deleted and unreferenced cache entries freed until there is sufficient space to continue processing.