On Jun 14, 2007, at 8:32 PM, Gustavo Pichorim Boiko wrote:

> On Thursday 14 June 2007 22:02:17 Matt Rogers wrote:
>> On Jun 14, 2007, at 9:21 AM, Gustavo Pichorim Boiko wrote:
>>> On Wednesday 13 June 2007 12:30:34 Olivier Goffart wrote:
>>>> Le mercredi 13 juin 2007, Gustavo Pichorim Boiko a écrit :
>>>>> Hi
>>>>>
>>>>> After thinking a bit more about that subject, I've got to write a
>>>>> proposal on that subject.
>>>>>
>>>>> http://people.mandriva.com/~boiko/kopete/user_info/
>>>>
>>>> From your page:
>>>>> One approach to simplify that would be to share a single identity
>>>>> across
>>>>> all protocols, but this does not fit in all cases (for example,  
>>>>> in a
>>>>> jabber account used for work contacts, you might want to put a
>>>>> different
>>>>> photo than the one you would put in a personal account), and  
>>>>> for the
>>>>> uncovered cases we still lack a solution.
>>>>
>>>> That's the point of having multiple identities.
>>>>
>>>> My idea of a identity is the same as a meta-contact.  (or like a
>>>> meta-account) An Identity contains accounts like a meta-contact
>>>> contains
>>>> contact.
>>>
>>> Ok, so I'm creating a branch work/kopete/identity_refactory to
>>> start working
>>> on this. The plan is:
>>>
>>> - Each account will belong to exactly one Identity.
>>>
>>> - Each identity can have one or more accounts associated to it.
>>>
>>> - Accounts can be moved from one identity to another
>>>
>>> - Properties (such as nickname/photo/personal info and so on) will
>>> be stored
>>> in the identity rather than the account.
>>>
>>> - Accounts should get/set properties from the identity rather than
>>> having
>>> their own properties.
>>>
>>> - Synchronization will be handle in the following way:
>>>   * If you set a property in the identity, it will be applied to
>>> all accounts
>>> belonging to this identity
>>>   * If a property changes server-side for one of the accounts in
>>> the identity,
>>> the user will be asked if he wants to have that property sync from
>>> server to
>>> the identity (and therefore to all other accounts), and, of course,
>>> provide
>>> the "Do not ask again" option. If there is only one account in the
>>> identity,
>>> do not ask and only apply the settings
>>>
>>> - The "Global Identity" will be a convenience for moving all
>>> accounts to a
>>> single identity (and maybe show an interface to unify the
>>> properties that are
>>> different in the old identities). The old identities will be
>>> removed (this
>>> can be discussed though).
>>>
>>> - The user info interface (the one I described in my proposal) will
>>> get/set
>>> properties from the identity, not from the contact
>>>
>>> - The property framework should (probably) be moved to the identity
>>
>> What do you mean by this? The property framework is needed at the
>> protocol level as level for the so-called private properties.
>
> Forget about this topic, I was missing the fact that the properties  
> at the
> contact level are needed for, huh, contacts ;)
>
>>> - The Akonady support will probably be implemented on top of the
>>> identity
>>
>> huh? the akonadi support is about storing the contacts (at the very
>> least) from the protocols in the akonadi database and implementing
>> addressbook integration, etc.
>
> Ok, this topic was completelly wrong.
>
> After discussing a bit with Gof on IRC we got something interesting:
> We will move the property stuff to a class (named PropertyContainer or
> whatever better name someone suggests).
>
> This makes it possible to use it from Kopete::Identity (and from  
> other places
> too) and it also make it possible to use the user info interface of my
> proposal on top of that.
>

Can you expand on this? I don't understand what all is meant by the  
above (PropertyContainer)

>>> Any complaints? :)
>>>
>>> Cheers
>>
>> Yes. I want to be able to associate an account to more than one
>> identity.
>
> And then we start to have problems on deciding (at the account  
> level) from
> which identity properties should come from, increase the complexity on
> solving synchronization problems, etc. Is it really worth adding such
> complexity?
>
> Besides that, having accounts in more than one identity at the same  
> time would
> imply on creating more  complex interfaces for setting this up  
> (which is
> something we could avoid).
>
> What do you think?
>
> Cheers

I think the original way is fine now. :)

Matt


_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel

Reply via email to