Contacts Storage

From Ekiga
(Difference between revisions)
Jump to: navigation, search
(GmContactsStore)
Line 1: Line 1:
 +
=== How does SIP Presence work ? ===
 +
 +
SIP Presence can work in 2 different ways :
 +
* We send a SUBSCRIBE for each contact for who we want to know the presence information. It creates a dialog, and we will receive NOTIFY messages indicating the presence information as long as the corresponding SUBSCRIBE has not expired.
 +
* We send a SUBSCRIBE to a ressources list using a RLS server. In that case, only one SUBSCRIBE is being sent. We will receive NOTIFY messages indicating the presence information for the global ressources list as long as the SUBSCRIBE has not expired.
 +
 +
 
=== What is XCAP ? ===
 
=== What is XCAP ? ===
  
Line 7: Line 14:
  
 
We will be using the same naming convention than in GTK+, as they are easy to remember and correspond well to the model we are trying to implement. Each area where we are able to store contacts is a GmContactsStore.
 
We will be using the same naming convention than in GTK+, as they are easy to remember and correspond well to the model we are trying to implement. Each area where we are able to store contacts is a GmContactsStore.
 +
 +
Each GmContactsStore is identified by an URI. It is already the case right now, and it will be the case for the XCAP GmContactsStore too.
  
 
We have several types of GmContactsStore :
 
We have several types of GmContactsStore :
Line 12: Line 21:
 
* ''GmEdsContactsStore'' : to access and store contacts in Evolution-Data-Server
 
* ''GmEdsContactsStore'' : to access and store contacts in Evolution-Data-Server
 
* ''GmAvahiContactsStore'' : to access contacts in your neighbourhood
 
* ''GmAvahiContactsStore'' : to access contacts in your neighbourhood
* ''GmXcapContacts'' : to access and store contacts in an XCAP backend
+
* ''GmXcapContacts'' : to access and store contacts on an XCAP server
 +
 
 +
=== GmContact ===
 +
 
 +
We will store contact information in a GmContact. Each

Revision as of 09:09, 2 May 2007

Contents

How does SIP Presence work ?

SIP Presence can work in 2 different ways :

  • We send a SUBSCRIBE for each contact for who we want to know the presence information. It creates a dialog, and we will receive NOTIFY messages indicating the presence information as long as the corresponding SUBSCRIBE has not expired.
  • We send a SUBSCRIBE to a ressources list using a RLS server. In that case, only one SUBSCRIBE is being sent. We will receive NOTIFY messages indicating the presence information for the global ressources list as long as the SUBSCRIBE has not expired.


What is XCAP ?

XCAP is a simple way to store contacts on a remote server using an HTTP connection. It does not manage presence, it does not have any specific feature. The only thing you can do is store a contacts list using an XML file.


GmContactsStore

We will be using the same naming convention than in GTK+, as they are easy to remember and correspond well to the model we are trying to implement. Each area where we are able to store contacts is a GmContactsStore.

Each GmContactsStore is identified by an URI. It is already the case right now, and it will be the case for the XCAP GmContactsStore too.

We have several types of GmContactsStore :

  • GmLdapContactsStore : to access LDAP contacts
  • GmEdsContactsStore : to access and store contacts in Evolution-Data-Server
  • GmAvahiContactsStore : to access contacts in your neighbourhood
  • GmXcapContacts : to access and store contacts on an XCAP server

GmContact

We will store contact information in a GmContact. Each

Personal tools