Contacts Storage

From Ekiga
Jump to: navigation, search

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.

You can store contacts who are not in your domain in an XCAP contacts list.

You can store a ressources list, but also authorization rules on an XCAP server.


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
  • GmXcapContactsStore : to access and store contacts on an XCAP server

GmContact

We will store contact information in a GmContact. Each GmContactsStore can have its own GmContact derivating from the main GmContact class (e.g. GmLdapContact) if more attributes need to be defined. This is not mandatory.

Each GmContact is uniquely identified through his URI, which can be of type SIP, H323, IAX or anything else.

GmContact at least has 2 operations :

  • const PString & GetStatusInfo () : Returns the status information. Unknown means we do not know yet. Not Supported means that we can not subscribe to the presence of the given contact. Any other value indicates a valid presence information.
  • GmContactsStore & GetContactsStore () : Returns the associated GmContactsStore for the given contact.

The URI is not the only way to contact a GmContact. There can be alternative ways (using a phone number for example).


Generic operations on a GmContactsStore, signals and properties

  • BOOL AddContact (GmContact *contact) : triggers the "contact-added" signal once the contact has been added
  • BOOL UpdateContact (GmContact *contact) : triggers the "contact-updated" signal once the contact has been updated
  • BOOL DeleteContact (GmContact *contact) : triggers the "contact-deleted" signal once the contact has been deleted
  • const PString & GetName () : returns the GmContactsStore name
  • const PString & GetURI () : returns the GmContactsStore URI
  • PSafePtr <GmContact> GetContacts () : returns a safe pointer to the first GmContact object of the PSafeCollection. The ++ iterator will send back a pointer to the next one.
  • static PSafePtr <GmContact> GetAllContacts () : same as above, but for all active GmContactsStore.
  • static PSafePtr <GmContactsStore> GetStores () : returns a safe pointer to the first available GmContactsStore object of the PSafeCollection. The ++ iterator will send back a pointer to the next one.
  • BOOL IsWriteable () : returns TRUE if we can use AddContact and UpdateContact on the GmContactsStore.
  • BOOL IsReadable () : returns TRUE if we can use GetContacts () on the GmContactsStore.
  • BOOL HasSignals () : returns TRUE of the "contact-added", "contact-updated", "contact-deleted" signals are available for the given GmContactsStore. Typically, the GmLdapContactsStore will not support them. It means the UI will have to refresh the list of contacts to be informed of updates. If signals are supported, they are triggered each time a GmContact has been added, either through AddContact() or through any other external mean (directly from Evolution for example).

GmContactsView

A GmContactsView is a GObject in the GTK+ implementation which displays the GmContacts in a given way, and allows actions on them. We can see at least two GmContactsView : GmRosterContactsView and GmAddressBookContactsView. The are an aggregated view of all contacts of all backends.


Location of the files in the sources

The GmContactsStore implementations should go in lib/gmcontacts2/ (we'll rename later). The GmContactsView implementations should go in src/gui/


How do we subscribe to presence information ?

We can manage presence through a new endpoint placed in src/endpoints/ : GmPresenceEndPoint. That GmPresenceEndpoint will use the GmContactsStore to :

  • subscribe to a RLS if allowed. In that case, the RLS server could allow subscribing to presence information of contacts who are not in your domain.
  • send individual subscribe requests if RLS is not allowed


When we add a GmContact, where do we add it by default ?

We can let the user choose, but use simple descriptions : "Local Storage", "Server Storage".

Personal tools