[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 13:09:26
[Download RAW message or body]

On Sunday 02 June 2002 14:06, Daniel Stone wrote:
> Yes, but I still think this method is icky. Personally, I don't think we
> should store any data locally, because I don't see the need to bloat
> Kopete severely and cause us severe implementation headaches just so we
> can rename contacts locally. And, of course, you get the sync problems.

That's a big plus I want to have myself. The real reason is that not everyone 
has a 1mbit DSL connection. I know from personal experience that retrieving a 
rather large MSN contact list on a slower serial cable modem is annoyingly 
slow. MSN however has a serial number associated to each contact list 
revision. If Kopete would store the list locally the sync would instead 
merely be a INCREMENTAL update since the last stored local copy.

This kind of caching might be MSN specific, but it can be emulated in the 
other protocols as well, even if the server doesn't explicitly support it. In 
other words: local caching is required anyway and it gives is the ability to 
implement a whole load of other options for free.

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.

> Until the servers can give us a transaction log of everything that's
> taken place so we can reliably compare times of what was done, this
> isn't really a goer.

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.

> > Implementation detail. Already discussed, because I somehow expected
> > that. Solution: designate one 'primary' group where the contact is
> > physically located on the server. The other groups are more or less just
> > symlinks handled by Kopete's contact list internally.
>
> Again, this comes back to the "store contacts locally" bit, which I
> really don't like.

And which I really insist on to implement for the reasons mentioned above, 
amongst others.

> Well, as I said, JabberContact/JabberResource has a pretty reasonable
> implementation, since we've needed to do almost the exact same thing.

Hmm? Could you explain? Does jabber have an _internal_ concept of meta 
contacts?

> I thought this over and thought it the cleanest approach. We should,
> however, designate this QString as NOT TO BE USED except for comparing
> two contacts. EVER.
>
> Storing contacts locally sounds like a really good idea until you get
> down to it, at which point it just becomes ewwie-ewwie-eww. Server-side
> contact storage is much more beneficial, and I think we should embrace
> it, instead of treating it like an ugly side-effect to be worked around.
> It's also a mess to implement, and I already have a *huge* TODO for 0.5.

That's exactly what I want as well. The different between us two is that I 
consider a local cache 'embracing it' and you consider it a 'workaround'. If 
I truly wanted to work around the server list I probably could ignore the 
server side list completely and invent my own client-side list. Not entirely 
sure, but I think MSN will let me get away with that. However, that's 
completely the opposite of what I want.

I completely agree that it is difficult, but that's actually part of the 
challenge for me. And wrt your todo list: I want to implement this myself 
mostly, and implement it for MSN first in a transitional way (i.e. not 
affecting the other plugins, unlike the KMM excercise). After that all 
plugins should be ported, but with a working MSN that should be relatively 
straightforward. And until the port you can more or less do whatever you want 
in your plugin as long as you don't change libkopete's contact list code, 
which is the only API part that's deprecated. All in all it should hence 
hardly affect you, except for the real porting, but I want to make that as 
easy as possible. And with a sane API it should be rather easy to document 
the steps to be taken as well.

> Psst, UI people: I repeat my call that's been out for a month to PLEASE
> look at all of Jabber.

I don't have time for that, sorry. Maybe someone else has? Most people here 
seem to dislike usability and GUI work at all, and I simply can't do this 
myself anytime soon. You could of course ask politely on kde-usability, myabe 
someone there can help you. But with Jabber (and Kopete itself BTW) being a 
fast moving target I don't know if we should spend too much time on usability 
already. Rather do that a few weeks before release, while settling the API. 
Generally API changes need waaaay more time to stabilize.

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]