Re: [Ekiga-devel-list] Ekiga address book searching by URI

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 15/11/10 20:30, Julien Puydt wrote:
> Le 15/11/2010 18:52, Eugen Dedu a écrit :
> > On 10/11/10 21:01, Julien Puydt wrote:
> > > Le 10/11/2010 19:24, Eugen Dedu a écrit :
> > > > Julien, any idea?
> > >
> > > Yes. At one point we discussed that with Damien.
> > >
> > > The naive way to do that is to add a get_uri method here and there, so
> > > you just loop, ask for the uri, and when you find a matching one : ask
> > > the name! It's so naive it won't work :
> > > (1) why would every contact have a single uri? It could have zero, or
> > > much more. For a contact in your typical addressbook, you certainly have
> > > several mails, perhaps an MSN, a SIP and a skype...
> >
> > Is this a problem for search_uri? You just show the contact who has this
> > URI (no matter how many URIs he has).
>
> The fact that you wrote "*the* contact" is wrong. There can be several
> contacts with the same uri.

Well, a contact can have 0 or more URIs; the same URI can be found in 0 
or several contacts.  So let's choose the *first* contact which has the 
URI we are searching for.

> > So who writes the get_uri function? This would allow to advance/finish
> > Grigory's implementation.
>
> There can be no get_uri. A single contact can have several uris.
>
> What about :
> - each contact has a bool has_uri (const std::string uri) const method ;
>
> - the Ekiga::Book class has a std::set<Ekiga::ContactPtr>
> get_contacts_with_uri (const std::string uri) const method, which uses
> the previous to build its answer ;
>
> - the Ekiga::Source class has a std::set<Ekiga::ContactPtr>
> get_contacts_with_uri (const std::string uri) const method, which uses
> the previous to build its answer ;
>
> - the Ekiga::ContactCore method has a std::set<Ekiga::ContactPtr>
> get_contacts_with_uri (const std::string uri) const method, which uses
> the previous to build its answer ;
>
> - finally the UI just has to call the previous, and choose one of the
> list...
>
> I think it handles nicely several things :
> - it assumes at no point that there will be a single uri per contact ;
> - it assumes at no point that a uri is associated to a single contact ;
> - at each level, the code should be pretty small.
>
> How does it look?

I Would prefer fewer methods, if possible, but you know the code better 
than me.

Grigory, any comment?

--
Eugen