[Adium-devl] Metacontact Plans for Adium 1.1

[Graham Booker]

On Sep 29, 2006, at 6:18 AM, Peter Hosey wrote:

> On Sep 29, 2006, at 04:02:31, Andrew Harvey wrote:
>> The question then arises …, how do we deal with addresses … which  
>> are in multiple groups?
>
> Since an AIContact represents a person, I think an AIContact should  
> enforce all of its AIAddresses' presence in *all* groups (or the  
> first group, if a protocol doesn't support multi-group contacts).  
> You wouldn't remove an AIContact from the whole list anymore; you'd  
> remove it from a group. The AIContact is only removed from the  
> whole list when you remove it from the last group.
>
> Thus it wouldn't be possible to have a contact in group A with  
> addresses A, B, and C, and another contact in group B with  
> addresses C, D, and E; contacts would be uniquified by addresses in  
> common, and each uniquified contact's addresses would then be  
> enforced in all of the groups that any address of the contact is  
> in. So there would be *one* contact with addresses A, B, C, D, and  
> E, and it would be in both groups A and B.
>

I can offer how we dealt with this situation in Fire.  Both the  
Addresses and Contacts had an NSSet of groups.  The address had an  
NSSet of Contacts. We just enforced that an address must belong to  
the union of its contact's groups.  So, in the above case, addresses  
A and B belong to group A, addresses D and E belong to group B, and  
address C belongs to group A and B.  I don't see the need for a  
contact with addresses A, B, C, D, and E to exist in both groups.  My  
proposed design doesn't disqualify it, but doesn't require it either.
Say, for instance, that buddy B is added to group C on the server.   
The a new Contact is created to contain buddy B within group C.

For services which don't support multiple groups for a buddy, we  
simply used the first group.  When the last group is deleted, then  
the contact is deleted from the server side list.  I suppose that  
Fire had an easier time doing this because it had a local list, and  
would synchronize with the server side list.  Also, the calls to the  
"Account" class were along the lines of "addBuddy:toGroup:" and  
"removeBuddy:fromGroup:" to handle this situation.

- Graham

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060929/59f08966/attachment.p7s>