[Adium-devl] Metacontact Plans for Adium 1.1

[Alan Humpherys]

I will add my bias here that the flexibility in the solution Graham  
describes allows for the simple case of a 1-n tree as well as the  
power user case of a person appearing in multiple groups (with  
certain screen names in group "work" and others in group "home" for  
example), but they would both tie back to the same address book entry  
(in the Apple Address book)

As someone who is forced to use other clients on Windows systems, or  
official AV clients on the mac, I can't stress how IMPORTANT it is to  
honor the server side buddy list and grouping.

If the service supports server side handling of buddy groups, we need  
to honor and maintain that grouping within the Adium code, so that  
changes made in the official client are propagated to Adium and visa  
versa.

It is only for those (backwater) IM services which don't support  
server side grouping that Adium would control the grouping itself by  
maintaining a local cache.

This means that each service would have to be categorized into 3  
buckets, and the code would have to enforce the rules imposed by  
these services:

1) We don't know groups
	Legacy MSN
2) Server Side grouping with a buddy in one group only
	Yahoo, AIM-TOC
3) Server Side grouping with multiple groups allowed
	AIM-Oscar

This makes the code and UI more difficult to make intuitive, but  
provides the best experience for users that have to be cross platform.

The good news is, I bet that 99.999% of users just want to have the  
simple (1-n) tree structure of  group -> person -> screen name.  That  
was the whole premise which drove the requirement to give us the  
concept of a Metacontact (ÜberBuddy, PersonItem, or whatever you want  
to call it.)

Alan
______
Alan Humpherys
alan at ewonderz.com



On Sep 29, 2006, at 7:45 AM, Graham Booker wrote:

>
> 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
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

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