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

[Julien PUYDT <jpuydt free fr>]

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

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

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

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.

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 !

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 ?