Re: [GnomeMeeting-devel-list] Refactoring of the addressbook code

[Julien PUYDT <jpuydt free fr>]

�ic Bischoff a �it :
> > You will need to keep a copy to show them to the user anyway.
>
> Keeping contacts in memory is not the same at all as keeping an image of what 
> Ekiga has to display of them. The GUI needs basically a list of strings to 
> display, not the potentially complex data structure of an address book 
> contact.
>
> Having one of these complex structures in memory at a time is enough IMHO.

Not at all. And it won't allow you to update informations like presence 
easily.

> Should it be only for performance reasons: when the user scrolls down the list 
> by one contact, it is much quicker to retreive data from a prepared list of 
> strings than from the contact itself.

The contact isn't that much more than strings...

> > And notice 
> > that a same contact could be shown at several places through the user
> > interface!
>
> Yes, and perharps displayed in different ways.

Yes, that too.

> > > No, and this article does not contain the word "roster" :-(.
> > The "roster" is the list of 'dead' contacts. I use 'dead' to distinguish
> > them from 'live' contacts.
> >
> > The situation is that you may have jc jabber lat in your roster, with
> > the information that the name is "Julius Caesar", and belongs to the
> > groups "Politicians" and "Jokers". But when he connects from his pda, he
> > will show up as jc jabber lat/pda, and will neither be able to do VoIP,
> > nor receive XHTML messages. When he is home, he connects from his
> > computer as jc jabber lat/home, and will be able to do both. Now he goes
> > to work, from where he shows up as jc jabber lat/work, which can do
> > XHTML messaging, but not VoIP.
>
> Aha.

Yes, it's that bad :-/

> > > Thanks for your openess, Julien :-).
> > No problem. More brains means better solutions :-)
>
> Yes, indeed. I hope my advice brings something constructive. As I told you in 
> private, you keep it or throw it, it's your decision.

Last time you wrote that I ended throwing both your ideas and mines ;-)

> > > I know. But I think it is always good to remove references to libraries
> > > if you do not really need them.
> > Well, glib is nice. The main problem KDE problem have with it is that it
> > begins with a 'g' and is already used in GNOME. :-)
>
> Do not believe that. We are not religious people. For example, we are very 
> happy sharing libxml with GNOME. Even though there is already a XML API in 
> Qt! Just because libxml rocks...
>
> (oh yeah, there's no "g" in libxml... ;-) )
>
> We already share libxml, desktop files, DocBook documentation, DBUS 
> communication, po translation memories, and many, many other things. Cool 
> apps like Ekiga can run in a KDE environment. Cool apps like ... errr... 
> KEuroCalc ;-) can run in a GNOME environment. And in fact I know that many 
> people do that.

What is KEuroCalc ?

> In fact, the more we will be able to share with you, the happier we will be. I 
> can ensure you that this has always been what we said, even during private 
> discussions at KDE meetings.

This is why it's so important to have a good DBUS component. And this is 
made easier by using glib-object :-)

> I do not know why we do not share glib. I have my ideas about that, but it's 
> just personal assumptions ;-).

I can make a few guesses :
1) it does things that QT does ;
2) it does things that C++ STL does.

Snark