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

[Damien Sandras <dsandras seconix com>]

Hi,

Le lundi 29 mai 2006 à 11:21 +0200, Julien PUYDT a écrit :
> Hi,
> 
> this is what I have in mind concerning the reorganization. It can still
> move a lot, should a flaw be found.
> 
> There should be "sources" of "addressbooks". From a source, I would ask
> the following:
> - can give a name to show the user
> - can give a short explanation of what it does
> - can answer the question: "Can you create an addressbook ?"
> - can create an addressbook (conditionnally to the answer to the
> previous question)
> - can return a list of already existing addressbooks
> - can notify when it creates a new addressbook
> - can create views for its addressbooks
> 

So a source can contain several address books: remote, local, avahi, ...

I would simplify this: a source is an address book, and several types of
address books are available. 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.

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


> 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.
For example, the user will get a list like :
- LDAP
- ILS
- Bonjour


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

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

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

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

> Questions
> =========
> 
> *) I'm not exactly sure how to manage the various actions available on
> an addressbook or a contact ; I'm pretty sure it will use GtkAction and
> the rest, but not sure how.
> 
> *) How would drag'n drop work ?

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