DesignBuddyList » History » Revision 63
Revision 62 (Adrian Georgescu, 01/28/2010 01:25 PM) → Revision 63/115 (Adrian Georgescu, 01/28/2010 01:30 PM)
= Presence blueprint = [[TOC(DesignBuddyList, depth=2)]] This is a High Level high level representation of a mechanism that maintains a '''Contacts List''' list''' and handles Subscriptions, Publications subscriptions, publications and Notifications notifications that can be used by a SIP client with a graphical user interface. GUI. It implements a combination of SIP SIMPLE standards related to presence event package, storage and policy. == Contacts List == ''Contacts List'' contains is a list of contacts displayed by the GUI. To build this consolidated list, a the SIP client supporting multiple SIP accounts must perform for each account the steps from the ''Account'' section. Some contacts are marked to Subscribe to them for Presence information. The list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and we must mark the contacts that we want to subscribe to. Additional, one can store full names and other attributes for each contact by using extensions to PIDF for contact information (cipid extension). Based on received Notify messages for ''Event: presence'', each Contact has a '''presentity''' attribute that contains its own published information, the GUI can display attributes of it. Each contact can also publish properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via ''caps'' '''caps''' extensions to ''pidf''. pidf. == Storage == The SIP client maintains the '''Contacts list''' as a concatenated list of resource-lists stored locally or on XCAP servers corespondent to each SIP account. A Contact is stored on exactly one XCAP server to provide atomic transaction. When a Contact is added/modified/deleted the corespondent remote XCAP storage is accessed. The remote storage is set per Contact in the Add/Edit Contact dialog. Each Contact can belong to a Group. The SIP client will maintain a central Groups list by merging all found groups on all remote storages and will populate each Group with all recipients found for each of them. [[Image(BuddyList-Aggregation.png)]] == Account == On boot: If ''account.xcap'' is enabled * If ''account.xcap.xcap_root'' is not set, locate XCAP root by doing a DNS TXT lookup for xcap.example.com * GET XCAP application xcap-caps * GET XCAP application xcap-directory * For all supported applications returned by above step, GET their files and cache them locally * If ''account.xcap.subscribe_xcap_diff'' is enabled, sent Subscribe for ''Event: xcap-diff'' * if ''Icon'' application is enabled, GET the previous icon using HTTP request If ''account.presence.enable_publish'' is enabled * If ''pidf-manipulation'' application is supported by the XCAP server, update the pidf with its content and update GUI with the fact that we have server based PIDF set * Send Publish with the current pidf if pidf_manipulation is not set, let the user change his state manually if pidf_manipulation is set If ''account.presence.subscribe_winfo'' is enabled * Send Subscribe for ''presence.winfo'' * Initialize ''Watchers List'' for ''Event: presence'' based on received Notify If ''account.presence.resource_lists'' is enabled * Initialize the ''Contacts List'' by using the content of the XCAP document ''resource-lists'', filename ''index''. Initialize the ''Subscriptions List'' using the Contacts marked for ''Subscribe to Presence'' If ''account.presence.rls_services'' is enabled * Put the content of ''Subscription List'' initialized above to the XCAP document ''rls-services'' identified by SIP URI account-buddies@domain If ''account.presence.subscribe_presence'' is enabled * If ''account.presence.subscribe_rls_services'' is True send one Subscribe for ''Event: presence'', and header ''Supported: eventlist'' to account-buddies@domain * Else for each contact in the ''Contacts Lists'' send Subscribe for ''Event: presence'' While running * Refresh the XCAP server location based on DNS TTL * Reload XCAP documents based on ''Event: xcap-diff'' Notify == Policy change == * Based on Notify for ''Event: presence.winfo'' alert the user about new watchers and update the policy stored in the pres-rules XCAP document * PUT ''pres-rules'' document on the XCAP server Transformations are required to support the following functionality: 1. First degree watchers - access to entire PIDF 1. Second degree watchers - access to subset of PIDF 1. Third degree watchers - access to basic presence online/offline == Icon change == There is how OMA has specified such XCAP application [http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf Presence Content XDM Specification] Publishing end-point: 1. Generate a new random filename: XYZ 1. Build URL http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ 1. PUT the new icon document to XCAP server 1. Update <icon> element of pidf and PUBLISH new pidf 1. DELETE any previously uploaded icon file Subscribing end-point: 1. Parse <icon> element of pidf cipid extension received in NOTIFY 2. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ 3. Cache picture until next NOTIFY with diferent <icon> element is received