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

[Éric Bischoff <ebischoff nerim net>]

Le Jeudi 15 Juin 2006 22:46, Julien PUYDT a écrit :
> > OK. So that should not be a requirement, and certainly not a mechanism at
> > the core of the system. Just a nice plus.
>
> It *must* be at the core of the system. We _do_ want to update the live
> data when it changes.

Sorry, that was not clear. By "at the core" I meant "necessary for the address 
books to work".

> > Yes. You could have a few spare contacts before and after the user's
> > view. This algorithm is rather common.
>
> What do "before" and "after" mean ?

Records just before and after the ones that are displayed in sequential order.

> > I know that it cannot be _that_ bad and that I certainly misunderstood
> > something. But what?
>
> I certainly have issues with big books, and must find some satisfying
> way to handle them. But doing function calls to walk on a list where I
> could get the list and walk it myself directly, is definitely wrong.

What is wrong is to see that as a list ;-).

> Most operations are sequential when the book is static. When your
> contacts go online/offline/whatever, that certainly is random access,
> and I can tell you a first/current/next approach doesn't fly in such a
> situation.

I would not say "not fly" but it certainly becomes much more acrobatic, I 
agree.

> If I add a new addressbook type with a Foo capability, your designs says
> I have to modify the base class and add:
>
> bool canDoFoo ();
> void pleaseDoFooThisWay (...);
> void pleaseDoFooThisOtherWay (...);
> void etcFoo (...)
> (with all the virtual pure syntactic crap needed)

This "crap" is a lightweight modification since it is only one function 
declaration. No implementation. That is done in the subclasses, if necessary.

> My idea of right design is that if the new addressbook is the only one
> needing Foo, it will handle it himself (through a specific api that its
> view and controller will know and use).

Okay. Perharps the our differences in opinion is not that much on the 
programming design, but more on what the software has to do.

To me, an address book is just an address book, they are not that different 
one from the other. Ekiga need to dig through them to show names, categories 
and to pick up SIP numbers to call the people. I see a relatively homogeneous 
user interface, with more or less the same appearance (if not exactly the 
same) for the various address books. I have a "unifying" vision.

To you, all address books have very strong pecularities and the software has 
to adapt a lot to each of them, to take them to the maximum of their 
possibilities. The user will get different display, different menues, and 
even different functionality.

That explains why you want to put everything in the "drivers", while I want to 
put a lot of common logic in the "engine".

> > I think that we are both wrong here ;-). An address book could be big
> > (which you underestimated), and it could be moving (which I
> > underestimated).
>
> I agree I have issues seeing how to do things *properly* with a very
> large addressbook.

Yes, and I have certainly underestimated the "dynamic" aspect :-(.

> Your view isn't OO, and isn't C++.

Come on ;-).

> You see functions named "methods" stuffed into the same poor base class,

No. Again and again, the base class only has declarations. It sees an 
abstraction of what the address book is.

In every C++ book, you can see examples like this

	class vehicle {
		virtual void accelerate(int a) = 0;
		...
	};

	class car : public vehicle {
		virtual void accelerate(int a);
		...
	};

	class plane : public vehicle {
		virtual void accelerate(int a);
		...
	};

Planes and cars have very different ways to accelerate. Planes can't brake and 
cars can't fly, but such designs are clean and very popular.

> Well, at least we both agree I don't handle the case of very large
> addressbooks very well :-/

Yes, this discussion is not pointless :-).

And at the end if you are more comfortable with libraries of C functions than 
with subclassing and virtual functions, it's no problem. After all, it's you 
who are going to be doing the dirty work (and I think we all thank you for 
that!).


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