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


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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]