[GnomeMeeting-devel-list] Ideas and considerations for the addressbook code

[Julien PUYDT <jpuydt free fr>]

Hi,

in private mails (with quite big attachments since I provided some 
sample stupid code), �ic Bischoff found my code not that explicit 
concerning what I have in mind. Since I would like to keep things as 
opened as possible, I drop my text here :-)

Let's see if I can manage to give useful ideas.

***** BIG WORDS

Model - View - Controller


***** VIEWING (GENERIC)

We need to be able to present a book to the user. For that, the view 
needs to have a list of contacts (no, a single contact definitely isn't 
enough!). So we need a function call to get a list of contacts.

The problem is that this list will change during time (new contacts 
added, others removed, presence changed, status message changed, and the 
list goes on). So the view will need to be notified about it. Hence the 
idea that the book will have "contact-added" and "contact-removed" 
signals, and the contacts a "updated" signal.

In addition to that, there is an interesting special case to handle : 
you have a contact in a book, and this contact shows up in a search 
result. When you remove the contact from the book, we want to make it 
disappear from the list too. Hence a "removed" signal for contacts.

Now this is all nice, but what can we do if an addressbook contains 
millions of entries ? And if a search gives thousands of results ? In 
such cases, my stance is that the low level code should do something 
about it, since it is the one giving the problem. How can the high level 
code cope correctly with the situation anyway ? Only the low level code 
can say "Eh, I already made two hundred contacts go through the wire for 
that search, perhaps I should make it easy!".

The question to really ask, and to which I have no satisfactory answer 
is: "How do me make the low level tell the high level it had to cut the 
list ?".

***** VIEWING (CONTACTS)

The contacts should contain enough to be viewed from a generic view in 
the contacts window, and be shown in a search result. That won't prevent 
some other parts of the code to make a better use of them.

For example, in the contact window we will probably be able to see a 
contact's title and description, but not its detailed presence, while 
the main window will contain a much better and more specific view for 
the live contacts.

***** CONTROLLING (GENERIC)

Now, we want to be able to act on our objects ; say rename a book or a 
contact, subscribe/unsubscribe to its presence, etc.

The best thing to do is to be able to get menus for each of them. Notice 
the plural: we will certainly to have at least menu in the menu bar and 
a popup menu.

The first bad news about such menus is that they won't be generic : they 
will depend heavily on the specific type of object (no rename for avahi 
contacts, subscribe/unsubscribe only for XMPP contacts...). So we will 
certainly need some sort of shared actions that will be basic bricks for 
building menu (like the shared-actions.[ch] of my first round of 
proposals), that each implementation will mix as it sees fit.

The second bad news about them is that they won't be static either. They 
will have to update themselves following the object they are attached 
to. Say your nice XMPP contact is connected with a client which has VoIP 
support, but now connects with a no-VoIP client, and disconnects the 
first : we want the "Call" menuitem to disappear to reflect this.

So my proposition (no code yet) is that those menus will be obtained by 
subclassing of GtkMenu, register to get signals from the contact/book 
they are attached to, and use that to keep themselves up to date.

***** CONTROLLING (CONTACTS)

Let's try to be more specific:
in avahi-contact-menu.h, we would have:
GtkWidget *avahi_contact_menu_new (AvahiContact *contact);
and in gm-contact.h:
GtkWidget *gm_contact_get_menu_new (GmContact *contact);

This later function would be different in each implementation, which 
allows for example the avahi_contact_get_menu_new implementation to call 
avahi_contact_menu_new. The high level code called a generic function, 
but got access to a very specific implementation, which knows the full 
api of the specific contact, and hence will provide the best service.

***** CONTROLLING (BOOKS)

Perhaps the menu shouldn't be attached to the book himself, but to its 
view. That would allow to place things such as "Show offline contacts" 
in it. Mostly the idea would be to have controllers for both the 
model-as-model and its view-as-model.


***** ABOUT EVOLUTION-DATA-SERVER

The evolution-data-server api looks pretty good -- except that it seems 
to mainly handle static vcard-based contacts, where I would like to be 
able to handle things like.

For example, we find a nice contacts-changed signal, but in the 
EBookView api... not in the EBook api, which seems strange.

***** ABOUT LIBGAIM

I shriek everytime I read/think about that comment in blist.h (just 
before the declaration of struct _GaimBuddy) :
"A buddy.  This contains everything Gaim will ever need to know about 
someone on the buddy list.  Everything." (sic).
and that one (before the declaration of struct _GaimContact) :
"A contact.  This contains everything Gaim will ever need to know about 
a contact."
and that one (before the declaration of struct _GaimGroup) :
"A group.  This contains everything Gaim will ever need to know about a 
group."

Notice that the comment before struct _GaimChat, although very similar, 
isn't so bad in my eye :-)

Notice too that although I find the way it is done inelegant, it still 
is very good and efficient to get the job done, and contains quite an 
impressive list of good ideas. (And it's more portable as ekiga, gasp!)

***** ABOUT LIBGALAGO

Why, why, oh why does it contain a GalagoList api which looks so much 
like a GList but isn't !?

Apart from that, I would say it looks nice, but is out of scope for what 
we want to do right now : it doesn't deal with addressbooks, but with 
persons as single.

"Using" it would be nice at some point.

***** LAST WORDS

Congratulations, comments and flames welcome, but flames will end in 
/dev/null.

Snark