Re: [GnomeMeeting-devel-list] [DRAFT] Organization of the "find contact" task

[Julien PUYDT <jpuydt free fr>]

Damien Sandras a écrit :
> So a source can contain several address books: remote, local, avahi, ...

A source doesn't "contain" addressbooks ; it manages them.

And I wouldn't make the separation like you think but more like :
- call history
- avahi
- evolution-data-server
- kde's stuff
- XMPP rosters
- SIP roster (maybe obtained by filtering another addressbook)

> I would simplify this: a source is an address book, and several types of
> address books are available.

A source is a "type of addressbook", in my mind.

> The programmer shouldn't have to deal with
> sources, he should only deal with address books. The type of address
> book is determined by the URL, the rest is transparent.

An url !? Definitely no. Each addressbook will have a type of its own 
(AvahiBook, EDSBook, CallHistoryBook...) all inheriting from the common 
very primitive GmBook.

> >  From the point of view of the "find contact" window, an addressbook is
> > mostly opaque :
> > - it has a name
> > - it can notify when the name changes
> > - it can notify when it is removed
>
> OK, so from the point of view of the programmer:
> - the user adds an address book, does it trigger a callback connected to
> a signal or not?

When a source creates an addressbook, it triggers a "book-added" signal. 
If you watch this signal, there are two cases :
- you only know you're getting a new addressbook, and can display it by 
its name, and ask the source for a specific view ;
- you know it's a CallHistoryBook, and hence can use the more complete 
api associated to it.

> > How would that work ?
> >
> > Situation: creation of an addressbook
> > =====================================
> >
> > In the "find contact" window, the user says it wants to create an
> > addressbook. The window polls the various lists, asking "Can you create
> > an addressbook?", then shows the user a window with a drop-down list of
> > the source names (the ones who said they could create an addressbook, of
> > course), and below that the short explanation of what the selected
> > source can do (which changes when the user goes through the list).
>
> Let's talk about address book types instead of sources.

That's mostly it. Except that AvahiBook would be a *type* inheriting 
from GmBook, while AvahiSource would be a source, inheriting from GmSource.

> For example, the user will get a list like :
> - LDAP
> - ILS
> - Bonjour

For the creation, he would see that in the drop-down list, but he would 
also have a nice tooltip explaining what each is.


> > Once the user chose the list, the "find contact" window tells the chosen
> > source to create an addressbook. At that point, the source opens a form
> > for the user to complete, and takes care of creating the addressbook. At
> > that point, the "find contact" window is free to do nothing. If the
> > creation worked, it will know it because the source will notify of a
> > creation.
>
> OK it answers my question.

The one about the signals, yes :-)

> > When receiving this notification, the "find contact" window adds the new
> > addressbook to its list (shows it in the left pane : it knows its name),
> > and also asks the source to provide a view for it.
> >
> > Situation: initialization of the "find contact" window
> > ======================================================
> >
> > The "find contact" window begins its life empty. Then when each source
> > is initialized, it registers itself to it.
> >
> > At that point, the window does two things :
> > - it asks for existing addressbooks, to show them
> > - it registers to be notified of new addressbooks, to be able to know
> > about them
> >
> > Situation: initialization of the SIP roster
> > ===========================================
> >
> > After the initialization of the main addressbook source, we can ask it
> > to create a view for us and embed it in the main window.
> >
> > Answers
> > =======
> >
> > *) why not use the same code to show all addressbooks as is the case
> > now? Because there's no "GmContact" anymore.
> >
> > *) why is there no "GmContact" anymore ? Because it just can't exist.
> > There's so little in common between all we can put in an addressbook
> > that it's better for each to manage its own stuff. For example we have
> > the SIP roster contacts which will come with presence, as the XMPP
> > contacts. But the avahi contacts won't. The XMPP contacts will have a
> > notion of being authorized, etc.
> >
> > *) does that mean no other part of the code will be able to make sense
> > of the contacts ? No ; take the DBUS component accessing the call
> > history as an example : it will directly access the call history, and
> > hence know the details. Only the "find contact" window will ignore the
> > details.
> >
> > *) why is it better ? Because instead of bending each and every 
> > addressbook out there (e-d-s, avahi, kde's, whatever) to fit into the 
> > existing api, we leave each manage things like it want !
>
> I think that we should have a common structure to hold contacts, like
> vcards for example. Otherwise, I do not see how we could program that.

Each source has the following function :
GtkWidget *gm_source_create_view (GmSource *source,
                                  GmBook *book);

So that the "find contact" window just has to do something like :

  view = gm_source_create_view (source, book);

  (void)gtk_notebook_append_page (GTK_NOTEBOOK (carnet->priv->notebook),
                                  view, NULL);

to add a view that is "native to the book" to its own display.

> Imagine the find window, we search for "Damien Sandras", it will return
> various items containing Damien Sandras:
> - from the calls history
> - on Ekiga.net
> - from Bonjour

Hmmm... it's not clear that would fly. I don't think searching can be 
done in a common way on all addressbooks.

> When right-clicking on the contact, we can send a message or call the
> user. It would be great if we had one unique function returning the URL
> to call from the contact. It is only possible if we keep GmContact (or a
> variation of it).

I don't think it's possible to have a common ancestor to all contacts. 
All actions should be bound to each specific implementation of a book.

Say we have a XMPPView which knows it displays a XMMPBook. Since it has 
access to all the api of such a book (and knows the actions possible for 
its contacts), it will be able to propose "authorize" or "unauthorize" 
depending on the state, and only allow "call" if the contact advertized 
a VoIP capability.

Snark