[Adium-devl] Metacontact Plans for Adium 1.1
timber at lava.net
Fri Sep 29 01:39:07 UTC 2006
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
> 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
> 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
> 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
> 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.
More information about the Adium-devl