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



Hi Julien,


and thanks for this nice document. That looks like a good basis for thinking 
aloud :-).

Le Jeudi 15 Juin 2006 10:54, Julien PUYDT a écrit :
> ***** BIG WORDS
>
> Model - View - Controller

Excellent basis.

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

In this paragraph I will assume that you mean "the view needs a list of all 
contacts from the address book driver". If it is not what you mean, please 
ignore this paragraph...

The view needs to display, say, 10 contects at a time. No need to keep a list 
of all contacts in memory.

All we "need" is a function that gets _one_ contact from the driver. The view 
can then use this information to keep the list of the 10 contacts that it 
currently displays.

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

While this sounds cool, I am not sure that this will be possible in some 
circumstances. The underlying address book (evolution, KDE address book, LDAP 
server, Zeroconf, ...) might not have the mechanisms to send such a signal.

I can imagine situations where some users on machine A update a LDAP server on 
machine B while Ekiga runs on machine C, with the network connection between 
B and C being temporarily broken. Will an update message come up to the 
driver, and if yes when and how?

Please notice that I do not know LDAP well and that such mechanisms might 
exist. Should that be the case, please ignore these paragraphs.

What do I propose instead? To be less ambitious, and have an address book that 
only pulls the data from the data source. If the user does not press 
"refresh", then he/she might have outdated information. If he/she presses 
"refresh", then the addresses are fetched again from the source.

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

I do not like that repartition of tasks.

Let me take an example. When you write an operating system, you write:
- disk drivers
  (the low level code that does physical read and write from and to
   the hard disk)
- a filesystem
  (the high level code that gathers individual sectors into files,
   handles a cache, etc)

The low level code should not be bothered with handling the disk cache. Okay, 
the problem comes from the disk driver, because it does slow access to the 
medium. That does not mean that it's not another component, the filesystem, 
that can solve it.

Why this repartition of tasks? Because the performance problem is a problem 
that can be shared by many disk drivers. Therefore, the solution can be put 
in common in the high level code.

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

Why transfer 200 contacts when the view knows that it needs only 10?

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

The views know that contacts 301 to 309 are displayed. It's the view that 
knows where to cut. In fact, there's nothing to cut, since all the view does 
is ask the driver for the contects it needs.

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

You say that the "contact" class must have _enough_ information to be used 
both in situation A and in sitation B.

It would be better to have _different_ "contact" classes for situations "A" 
and "B".

The list of contacts could just manage a name, a company and a phone number. 
The search result could handle much more detailed information.

In other words, there's no need to put all the model's data into the views' 
data. Each view can handle the data it needs.

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

I assume here that an 'implementation" is one of the address book drivers, and 
that you mean that the drivers will be in charge of building menus. If those 
assumptions are wrong, the paragraph below does not apply, please just ignore 
it.

Just the same as a hard disk driver does not display menus to the user, I 
think that the address book drivers in Ekiga should not be responsible for 
user interaction.

The high level code should be responsible for that. Of course the contents of 
the various menus depends on the address book capabilities. That's why the 
API between the driver and the high level code should include "query 
capabilities functions:"

	class addressBook
	{
		virtual bool isReadOnly() = 0;
		virtual bool canSubscribeContacts() = 0;
		...
	};

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

In your example, a signal is not needed.

Knowing that there is no VoIP number in the current contact is enough.

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

Again, this logic should be in the high-level code and needs not be 
avahi-specific. What exactly should be presented to the user could be 
determined from querying the address book for its capabilities.

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

Agree.

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

It definitly deserves congratulations. You forgot to mention one of your nice 
ideas, that it that it should be possible to search in several address books 
at a time.


For the comments, please note that my comments are based on a lot of 
assumptions and guesses. In particular, I assume that you have in mind a 
different assignment of tasks of the various software layers than the one 
that I would like to see. If those assumptions reveal wrong, then of course 
my comments do not make much sense.

If I did not misinterpret your thoughts, you have a very lazy view of the 
high-level code. It's software that sits down and waits for signals to act. 
Somehow, the high level code provides "services" to the drivers. The drivers 
are the ones who understand what's going on.

I have the opposite view: the address book drivers are simple and stupid. 
Their main task is to go and fetch the requested contacts. The high level 
code has an active attitude: it queries the drivers for contacts, it queries 
the drivers capabilities, it displays the contact windows, it handles the 
menues... The high level code has the real intelligence.


I hope that helps,


-- 
Concombre : "Alors, qu'est-ce que tu aimes dans la vie ?"
Chourave :  "J'aime médire."
(Le concombre masqué, Mandriva)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]