[Adium-devl] Metacontact Plans for Adium 1.1
Andreas Monitzer
soc at monitzer.com
Fri Sep 29 01:25:56 UTC 2006
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.
My code still contains a lot of minor bugs related to the fact that I
was missing some insight into the Adium core (for example, auto-
reconnect on wake from sleep or app launch doesn't work). Those are
all properly documented and should be easy to fix for someone with
more than 3 months of experience in that huge pile of code.
However, there's one major issue, which I identified very early on in
the development, but couldn't find any easy fix (even with the help
of some Adium devs). In XMPP, one account can be online multiple
times, using the concept of "resources", which is a unique identifier
for each of those connections. For example, one account could be
online from two different computers, one using the resource "Home",
and one using the resource "Work". Everybody sending messages to this
account can decide where it should arrive (there's a priority
mechanism similar to Adium's for selecting the right one).
In a way, this is similar to Adium's meta contacts (limited to a
single service). This causes some issues in Adium, since not all
contact list entries are meta contacts.
I tried to work around this issue in my branch by creating a new kind
of metacontact (called "SmackListContact"), which acts just like a
regular contact on AIM (which everything in Adium seems to be
designed for) and doesn't have any specific resource. For the meta
contact popup, I had to do some workarounds (involving removing -
isKindOfClass:[AIMetaContact class] method calls), because I suddenly
had three levels of contacts.
My workaround seemed to be a good solution. However, I switched to
using my branch full time for chatting about two months ago, to do
some beta testing. I've discovered many issues with this
incompatibility:
* The AIChat is associated with the AIListContact (which has a
resource), which means that all code that references the
SmackListContact will not affect the AIChat (this breaks typing
notifications for example).
* The underlying AIListContact doesn't duplicate all properties of
the SmackListContact, which means that it doesn't have the avatar or
its alias.
* The logs are associated with the AIListContact, which means that
the resource is included in the log's contact name.
* For some unknown reason, every time I receive a message from an
XMPP peer which is contained in a meta contact locally, I get the
meta contact popup, even though the messages all arrive from the same
resource.
* Receiving a message from a different resource of the same contact
you're already chatting with creates a new AIChat object (plus view).
It'd probably be possible to fix all those issues in the current
system, but that probably would mean a lot of hunting for -
isKindOfClass:-method calls, and some rewrites.
David Smith and Ofri Wolfus talked to me about this issue, and we
came up with a clean solution.
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.
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.
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!
andy
More information about the devel
mailing list