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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Contact List overhaul
From:       Daniel Stone <dstone () kde ! org>
Date:       2002-06-02 12:06:07
[Download RAW message or body]

On Sun, Jun 02, 2002 at 01:54:51PM +0200, Martijn Klingens wrote:
> On Sunday 02 June 2002 08:52, Daniel Stone wrote:
> > On Sat, Jun 01, 2002 at 09:58:43PM -0400, Duncan Mac-Vicar Prett wrote:
> > > > so, what are those flashy features ?
> > > >  - kopete will store contacts locally, and allow for synchronization
> > > > with the server for groups/contacts/contact info, if supported. there
> > > > are many advantages to doing this: being able to move users while
> > > > offline, being able to change the screen name to whatever we like, etc.
> >
> > No, no, no, no and no. This is fucking painful. What happens if you:
> > * Disconnect
> > * Log on to the same account on a different machine and change a screen
> > name * Change the same name to something different while offline
> > * Reconnect
> >
> > Which one do you use, the server one or the local one? This is just one
> > of my many bitches about this approach.
> 
> Those are implementation details, not requirements. I already discussed how I 
> want to implement that with Andres (Hint: the 'Set Nickname' option in MSN's 
> context menu with some extension, that one feature was my test case for 
> syncing values back and forth), but in this intial mail we DELIBERATELY 
> didn't want to mention any specific implementation. After all changed 
> requirements affect the implementation, but requirements themself can be 
> agreed upon or rejected rather easily.

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

> > > >  - contacts can be part of any number of groups, starting from 0 (ie no
> > > > group at all)
> >
> > Really funny until you get a protocol like Jabber which doesn't support
> > multiple groups.
> 
> 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.

> > > >  - contacts can be agregated into some "metacontacts", which will
> > > > represent a physical person. for example, if a friend of mine uses msn,
> > > > aim and icq, i'll be able to aggregate those 3 into one "metacontact".
> >
> > This is something that I have been arguing, yes. How to do it cleanly I
> > still don't know.
> 
> I already have a reasonable idea on how to implement it. Don't expect results 
> before I'm back from LinuxTag (June 12), but stay tuned.

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

> > > > these can be thought of as requirements.
> > > > since the overhaul is going to heavily change parts of libkopete, we'd
> > > > like to hear from protocol implementors (or people with good knowledge
> > > > about the protocols): do you want to add requirements ? (does your
> > > > protocol have feature X that needs support from libkopete's contacts
> > > > and contact list ?)
> >
> > I think the question is more: Can you implement all of this in your
> > protocol?
> 
> Not really. We asked here to identify which protocols have which capabilities. 
> If there is a reasonable chance one of our current or future protocols 
> doesn't support a certain feature either libkopete should emulate the feature 
> locally (like multi-group memberships), or make the feature itself optional 
> in one way or another. Preferably the former, but in some cases perhaps you 
> can't avoid that.

Oh, I'm not suggesting we go like GAIM and only implement what every
protocol supports; if I felt that way, I wouldn't have implemented
things like resources. There's more Jabber good stuff coming, too, e.g.
transports support, etc.

> > > > the contact/contact list overhaul will also attempt to tackle some of
> > > > the issues of the previous design. namely:
> > > >  - contacts right now are not good to work with, for a number of
> > > > reasons like: * nobody guarantees that two different pointers are
> > > > different contacts. * nobody currently tracks contact creation and
> > > > destruction, which leads to mighty crashes.
> >
> > Which is why I've been arguing for QString
> > KopeteContact::{protocol,uniqueID}. With these two, you could compare
> > contacts *reliably*.
> 
> Either that, or a single QString that represents a hash with both IDs 
> combined. The main problem Andres and I have with QString is that other parts 
> of the code can falsely assume a id represents an MSN passport, an ICQ UIN or 
> an AIM screenname, while the value should REALLY be treated as a 'string with 
> undefined content'. With a separate class for the ID this can be enforced in 
> the API, with a QString it cannot. But given the problems with a separate 
> class (plugin needs to be loaded to create an instance of the ID - Eek!) I'm 
> more and more inclined to opt for the QString as well.

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.

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

-- 
Daniel Stone	   <daniel@raging.dropbear.id.au>   http://raging.dropbear.id.au
KDE Developer	   <dstone@kde.org>	                      http://www.kde.org
Kopete: Multi-protocol IM client	    http://www.kdedevelopers.net/kopete/

[Attachment #3 (application/pgp-signature)]
_______________________________________________
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]