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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Contact List overhaul
From:       Duncan Mac-Vicar Prett <duncan () kde ! org>
Date:       2002-06-02 9:39:15
[Download RAW message or body]

El Saturday 01 June 2002 17:47, Andres Krapf escribió:
> hello everybody, this is yet another one of my long report mails :-)
>
> on #kopete, Martijn and i have discussed plans to get the latest flashy
> features in kopete's contact list.
>
> 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.

Not 100% agree with this

>  - contacts can be part of any number of groups, starting from 0 (ie no
> group at all)

as DannyS says, Jabber cant do this

>  - 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 the first thing we should do.
Kopete should be able to add people, and even you should be able to associate 
info with the person, ie: picture, etc

When you add a contact using a plugin, the add dialog should ask which Kopete 
meta person is this, so the plugin can associate it, I think Kopete should 
not store plugin data, just meta contact data, and the plugin should store 
the id of the person for every contact it have stored,
then, if a contact goes online, the plugin should tell Kopete that the 
metaperson is online in his protocol, and Kopete, in a consistent way should 
be able to present all information in whatever way the users want ie: 1 list 
entry per person, no matter how many protocols is this person in, grouped by 
person but distinguish between protocols, or just separated like used to.

> 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 dont think we will have to change too much, the contact list should be 
redesigned mostly.
I dont agree with fit kopete needs with the plugins, as already shown, there 
are plugings that dont support some features.

> 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.
>  - more code could be integrated in libkopete.

I agree with this, and I proposed my solution, that every protocol buddy 
should be associated with a Kopete person.

> Martijn has kindly offered to do the work. he'll start whenever he feels
> like it, probably soon enough... so if you want to react, do it quickly :-)

Do quickly, think slowly, and discuss, communicate.
:)

Cheers
Duncan

-- 
=============================================
Duncan Mac-Vicar Prett     | duncan@puc.cl  | 
KDE Developer              | duncan@kde.org |

http://www.mac-vicar.com   | ICQ: 31947372  |

- Kopete, The KDE Instant Messenger
  http://kopete.kde.org

=============================================
KDE 3.0, Konquer your Desktop. www.kde.org
=============================================
Public Key available at:
www.mac-vicar.com/~duncan/pgpkey.txt
Key ID      : 667E42D1
Fingerprint : 75DA 7B97 1FD6 ADB9 A880 BA9F CD1E B6A9 667E 42D1


_______________________________________________
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]