[Ekiga-devel-list] [IDEAS] Mixing contacts-ng and SIP presence

[Julien Puydt <jpuydt free fr>]

Hi,

the contact-ng code is based on the principle that whatever object knows
how to do something does it -- the rest shouldn't care about the details.

Come in SIP presence, where ekiga will need to subscribe to the presence
of contacts by their uri. That would mean the software component in 
charge of this needs to sift through all contacts and find if they have 
something it understand. Which would mean it knows about avahi, gmconf, 
ldap, evolution, kab, etc. Bad, bad, bad.

I tried to find a way around this, to have a clean design. So the 
principle is a new object, let's call it ContactSIPHelper (I come up 
with a different name each time I try to write it down -- help!). When a 
contact finds out it has a SIP uri, it registers itself to the helper 
with this uri, and then forwards part of its api through it.

More precisely, when the contact is asked its avatar (representing 
presence) or to populate a menu (representing available actions), then 
it forwards it to the helper, which will take care or answering on its 
behalf.

So if the contacts has a SIP uri, then the SIPContactEnabler will 
subscribe to its presence, determine if it's able to do text messages, 
audio/video calls, etc, and make it automagically available.

I'll have to modify a little my existing code to adapt to this idea : 
notably the shared action "call" makes no sense : the existing contacts 
should either know it's a phone number or a SIP uri and register to a 
ContactSIPDecorator and/or a ContactPhoneDecorator, which will take care 
of this.

There are still a few things unclear in my head though : what to do when 
a same contact has several phone numbers or worse SIP uri ? I say worse 
because there could be an easy way out for phone numbers : make the 
registration function take the contact + phone string + phone 
description (home, work, etc), and the PhoneNumberEnabler would add 
several actions to the menu.

But when there are several SIP uri... and several presences to mix, the 
problem is hairier. I thought perhaps in that case the "most present" of 
all uris of a contact would be the default presence shown, and would 
also be the first in the menu (ie : the order of the actions in the menu 
would reflect the presence).

Feedback welcome!

Snark