DesignBuddyList » History » Revision 45
Revision 44 (Adrian Georgescu, 08/04/2009 06:08 PM) → Revision 45/115 (Adrian Georgescu, 08/04/2009 06:13 PM)
= Presence blueprint = [[TOC(Design*, depth=1)]] This is a high level representation of a mechanism class that maintains a '''Contacts list''' that can be used by to manage a GUI. '''Contacts list''' driven interface of a SIP client graphical user interface. It implements a combination of SIP SIMPLE standards related to presence event package, its storage and policy. * Account * Contacts * Watcher list * Presence rules * Icon exchange * Preferences == Account == On boot If presence enabled * Initialize our own '''presentity''' * Initialize the '''watchers list''' * If '''account.presence.xcap_root''' is not defined, locate XCAP root by doing a DNS TXT lookup for xcap.example.com * GET XCAP application xcap-caps * GET the default filename for all applications supported in xcap-caps and cache them locally * If '''pidf-manipulation''' application is supported by XCAP server, update the '''presentity''' with '''pidf-manipulation''' document * Send PUBLISH for '''Event: presence''' * Initialize '''Contacts''' using XCAP documents * If '''account.message_summary.enabled''' SUBSCRIBE for '''Event: message-summary''' * If '''account.presence.subscribe_xcap_diff.enabled''' SUBSCRIBE for '''Event: xcap-diff''' While running * Refresh XCAP server location based on DNS TTL * Refresh PUBLISH for event '''presence''' * Refresh SUBSCRIBE to '''presence.winfo''' * Refresh SUBSCRIBE to '''xcap-diff''' * Refresh SUBSCRIBE to '''message-summary''' * Reload XCAP documents based on '''xcap-diff''' NOTIFYs * Update '''presentity''' based on GUI actions or automatic sensors and cache it Long term state * Update '''pidf-manipulation document''' and '''presentity''' == Contacts list == [[Image(BuddyList-Aggregation.png)]] Contains a list of contacts displayed in a GUI, for some contacts we SUBSCRIBE to for '''Event: presence'''. The contacts 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. Based on NOTIFY for Event=presence each contact has a '''presentity''' attribute that contains its published information. The GUI displays various attributes of each '''presentity'''. * The contacts list is stored in the main '''resource-lists''' XCAP document '''index''' * Maintain a '''presentity''' attribute with what is received in the Notify for each contact * If '''account.presence.subscribe_rls_services''' is true, a RLS document that contains a list of discrete SIP URIs we subscribe to and PUT it on the server under SIP URI account-buddies@domain. Then a Subscribe is sent with Supported: eventlist for this SIP URI. /otherwise send SUBSCRIBVE to each contact for '''Event: presence''' * On contacts list change, PUT resource-lists and rls-services documents on the XCAP server A contact has properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''presence caps''' and updates the preferences set by the local user == Presence watcher lists == Built based on the body of NOTIFY for '''Event=presence.winfo'''. == Presence rules == * Based on NOTIFY for event '''watcher.info''' we update the policy * PUT '''pres-rules''' document on the XCAP server and cache locally == Icon exhange == There is how OMA has specified such XCAP application: '"Presence Content XDM Specification'" http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf Support in OpenXCAP server is necessary, see http://openxcap.org/ticket/100 Publishing end-point, on boot: 1. HTTP GET for xcap-directory and locate previously uploaded icon (e.g. ABC) 1. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/ABC Publishing end-point, on change: 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. HTTP PUT to xcap server 1. Update <icon> element of pidf and PUBLISH new pidf 1. HTTP DELETE any previous icon file ABC Subscribing end-point: 1. Parse <icon> element of pidf 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 == Preferences == Managed the policy dependent on the Group the Watcher is in the Contact list.