[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Contact List overhaul
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-06-02 14:33:52
[Download RAW message or body]

On Sunday 02 June 2002 15:47, Daniel Stone wrote:
> How long does it take? On dialup, syncing my 120-odd contacts isn't
> altogether slow. Even on ISDN, it's *very* quick.

A 50+ contact list on a 512kbit ADSL line takes some 6 seconds to fully load. 
This includes creating the MSNContact instances and inserting them in the 
list, which is done at the same time.

And I have the slight feeling the latter is the truly slow part, but I haven't 
done any profiling to confirm that. That's also another reason why I rather 
want to load contacts in the background during Kopete startup rather than 
during connect: it makes the GUI 'feel' faster, because the connect is done 
way faster. The fact that the same amount of work is still done is much less 
noticable to the end user.

> > Another issue is that I want to see my contact list when I'm disconnected
> > as well. Again, this cannot be done without local storage.
>
> Eh? Why? :)

Several reasons. To name a few:

1. A contact is still a contact when offline. Consider the contact list like 
an address book. Do the telephone numbers disappear if you're not near a 
telephone? Technical issues aside, would you like it if they did? I don't.

2. The coming and going of contacts (deleting and creating them) causes some 
ugly side effects in e.g. open KMM sessions. Most of them will be gone with 
unique IDs, but having contacts being more persistent might be a plus.

3. Why would Kopete show groups if I'm offline, but not contacts? And why 
would Kopete show contacts for some protocols (ICQ for example), but not for 
the server-based contact lists like MSN and Jabber?

> > Why not? I really don't see the issue. Of course you can create a
> > synthetic race condition where two offline changes are synced in the
> > wrong order, but in those extremely rare cases the user will definitely
> > know this and not mind. I personally consider those situations rather
> > theoretical and nothing to worry about.
>
> Extremely rare? My situation isn't exactly a small edge case to trigger.
> I just think that putting our fingers in our ears and saying "RACE? WHAT
> IS A RACE?" until they go away isn't a good idea, nor is spending our
> lives trying to hack sanity into it.

Well, how often does it happen that you change the SAME setting on two 
different machines while offline (so the sync is not immediate) and then go 
online on both machines in the reverse order? That's the *only* case where 
you actually trigger the race, and I definitely consider this a synthetic 
race, that sane people won't trigger for real anytime soon.

> The caching makes sense for MSN, but absolutely no sense for any of the
> other protocols.

It does if you want to show contacts while being offline, if you want to use 
KDE's address book (I want to add that option to Kopete 0.6) and quite a 
number of other cases.

> It's also pretty fucking hard to implement for
> protocols like Jabber, because of the way Psi works (it maintains its
> own contact list et al).

That has never been an excuse. Technical difficulties are nice challenges, but 
should never affect the user experience. It is a problem for us developers to 
solve, but in the end it is the users who are the most important.

Also, the hard work will mainly be in getting this up and running (for MSN). 
Once that is stable (and with your valuable remarks about the differences 
between MSN and Jabber in mind) your part should not really be hard.

> Jabber's concept of resources is REALLY LEET.
>
> [ explanation skipped ]

Sweet indeed. Sweet enough to want that in other plugins as well. Any chance 
to emulate it libkopete if there's no protocol support for it? I guess not, 
but it's worth thinking about...

> As I said, Psi stores its own contact list, and keeps its own state.
> This means that we're going to have to juggle *four* contact lists:
> server, local storage, Psi, Kopete. That will be really messy, and

Hmm? Kopete's contact list == local storage by definition with my proposed 
changes. That makes it only three, and the same three already exist. The only 
difference is that the third contact list now exists as soon as the plugin is 
loaded (maybe even if it is not loaded?) and not only when connected. This 
means that during connect some offline changes may need to be synced, that's 
all.

> o Support file sending

Make that one generic through libkopete. Something like add the methods to 
KopeteProtocol, together with a method 'bool canSendFiles()' or so. IRC 
already has DCC which should use the same API, and file transfers for the 
other protocols should use it as well later on.

> That said, please don't piss too much on Jabber; I

Why should I? As I said I want to have it in MSN first and not even consider 
touching the other plugins until that. One (possible) exception: I may need 
to introduce new virtual methods to libkopete of course. Those *might* not 
always be source compatible. In those cases I will add the proper changes to 
the plugins, but those will then be solely 'keep it compilable, but maintain 
old behaviour' commits. And I don't expect to need any of those.

> still have an email address; use it. If you do something like add local
> contact storage to it while I'm gone, I'll slice your testicles almost
> all the way off. I'll leave them hanging by the nerves, and then leave
> them to soak in vinegar. Are we clear? :)

Politeness and diplomacy aren't two of your virtues, eh? ;-)

As said above, that wasn't my plan anyway. Any changes I make to the plugins 
WILL be discussed with the respective maintainers if they stretch beyond the 
'make it compile' level. Period.

Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]