[Adium-devl] Metacontact Plans for Adium 1.1

Graham Booker gbooker at cod3r.com
Fri Sep 29 04:40:02 UTC 2006


Sending again to the entire list (sorry for the dup Andreas)

On Sep 28, 2006, at 8:25 PM, Andreas Monitzer wrote:

> <snip>
> This solution involves rewriting the AIListContact-related code. We
> proposed a hierarchy, where every physical person gets assigned an
> "AIContact" object. This contact has a GUID, a name, an icon, etc
> (basically everything the contact list displays). It does *not* have
> a status. Additionally, it contains a list of "AIAddress" objects [we
> welcome any suggestions for a better naming scheme ;)]. An AIAddress
> object is associated with a specific screen name on AIM, UIN on ICQ,
> JID w/ resource on XMPP, etc, and contains a status.
> Before connecting, there are only AIContacts. When an account plugin
> senses that there are some contacts on the user's contact list, it
> wraps them in an AIAddress subclass and adds each of them to the
> specific AIContact they belong to.
>

Let me see if I understand this correctly.  Using your terms, the  
AIAddress is essentially a screenname.  This is just like everything  
was before we had meta-contacts of any sort.  There is a one-to-one  
correspondence between a screenname and an AIAddress.  Right?
The AIContact is a list of one or more AIAddresses.
The group in the contact list contains a list of one or more  
AIContacts.  This essentially forcing the contact list to display  
everything in a three level hierarchy.  Groups -> AIContacts ->  
AIAddresses?

If I understand this principle correctly, then this is exactly the  
structure we had in Fire.  There it was Groups -> PersonItem ->  
BuddyItem (may be better names to use).  The PersonItem served as a  
grouping of BuddyItems.  A BuddyItem always belonged to at least one  
Person, even if that Person had to be generated.


While on the subject of the contact list structure, I have some ideas  
for some changes.  I spent considerable time working out the details  
for this within Fire so I believe I have a solution to this issue.   
Buddies and Persons belonging to multiple groups.  Most services  
support this, but Adium does not.  In addition, a Buddy belonging to  
multiple Persons.  This accounting is not difficult if one keeps the  
groups in an NSSet.  I have the code that does all this already done  
in Fire, so we can use it as a model if necessary.
-------------- 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/20060928/00f68a5a/attachment.p7s>


More information about the devel mailing list