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

[Damien Sandras <dsandras seconix com>]

Le lundi 29 mai 2006 à 21:17 +0200, Julien PUYDT a écrit :
> 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 still maintain that this notion shouldn't be presented to the
programmer or to the user.

> > 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.
> 

You are probably going too far in complexity. Complex code leads to
complex problems, even more in C.

> >>  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.
> 

I do not have to know it is a CallHistoryBook. If I have to know it is a
CallHistoryBook, it means I will have to "special case" a lot of code in
the current code, adding many "switch" statements or "if" statements.

> > 
> >> 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.
> 

Inheriting in C?

> > 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.
> 

I don't think it is the correct approach, think to non-technical people.

> 
> >> 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.

I think it should be a prerequisite. Searching has to be done
transparently, without having to take care of where we are searching.
Look at how KAddressbook or Evolution-Data-Server are doing things. You
have several types of address books, but the API is the same for all of
them.

> 
> > 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.
> 

I think it is not a good way to handle thing, it will lead to code :
- complex to write
- having many special cases to be handled here and there in various
parts of the current code

Such code would be bad. I'm really not convinced by this part of your
approach.
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net