[Adium-devl] Metacontact Plans for Adium 1.1

[Colin Barrett]

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

> Hi devls,
>
> Since 1.0 is close to be finished (and none of my concerns ;), I
> spent the last few weeks discussing with other Adium developers about
> the plans for 1.1, since that's the point where my SoC-Code will get
> merged into the main branch.

Speaking of which, we should probably branch 1.0 pretty soon -- trunk  
is effectively "closed" at this point, and I think we can get some  
work done on 1.1 right off the bat and get that release out the door  
fairly quickly if we really focus on closing tickets like we have with  
1.0.

> <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.

This sounds like a good idea to me -- I had advocated the idea of  
"metas" being moved into the UI (rather than completely into the core  
like this proposal does); however I hadn't considered Jabber  
resources, and it seems like a compelling argument for doing things  
your way.

> What this basically means when talking in terms of the stuff that's
> already there, *all* contacts are wrapped inside meta contacts, plus
> there might be multiple contacts from a single account per  
> metacontact.
>
> As an example use case, sending a chat message can be done either by
> telling the AIAddress, which can do with that whatever it wants, or
> the  AIContact, which will decide what AIAddress belonging to the
> contact has the highest priority, and forwards the message to it.
>
> I talked to ofri about the possible implications to ChatKit. He
> agreed on rewriting the stuff he already has to use this same
> concept, and that we'll have to specify two @protocols, which both
> AIContact/CKContact and AIAddress/CKAddress (names subject to change)
> have to adhere to. This would mean that moving to ChatKit would be a
> simple drop-in replacement once it's ready for that.

Awesome. This is a good intermediate step for moving us over to  
ChatKit -- I suggest future refactors also take as much care in  
looking at how CK does things and possibly changing both APIs to be  
more alike.

> However, the downside of this plan is that it involves many micro-
> changes all around Adium's code, which is a non-trivial task. This
> will probably delay the release of 1.1 for a bit, depending on the
> time all developers can spend on it. I'd like to hear your input on
> that plan!

If it's a question of "impossibly dull" rather than "impossibly hard,"  
I think between the five(ish?) of us, we can get the whole source  
moved over to the new way in a branch in a few weeks. Once we finalize  
the new API, we should draw up some example documents for converting  
existing meta-contact code to the new system -- the less thinking we  
have to do when making these changes, the faster we'll be able to  
change things over.

In general, I think this is a good idea, and would be a good excuse to  
clean up AIContactController.m (ugh). All the more reason we should  
get started on this ASAP: i.e. branch for this as soon as we have an  
API outline finalized.

-Colin