[Adium-devl] Metacontact Plans for Adium 1.1

[Augie Fackler]

On Sep 28, 2006, at 9:39 PM, Colin Barrett wrote:

> On Sep 28, 2006, at 3:25 PM, Andreas Monitzer wrote:
>
> <snip hellos and such sundries />
> 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.

I suppose so, although we need to make sure changes get merged back  
to trunk from 1.0.

> <snip Andy's idea />
> 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.

I think handling things internally as a meta makes sense, seeing as  
most of the time that will be more useful in the long run. One thing  
I'd like to see in the new architecture is for capabilities like FT  
to be handled on a per-contact basis, as AIM and Jabber both support  
knowing different levels of ability per contact, which is something  
we really should do.

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

I'm still a little hesitant on CK. I think things like CK will be  
less valuable as we start getting some of the more intricate VV  
things happening, but we'll burn that bridge when we come to it. *If*  
a good solution for that can be found without making multiple heads  
asplode, then I think we're OK. Perhaps consulting the Vorlon again  
will help with 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!
>
> 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.

I've got time to do things like that.


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

Excuse nothing, we'll *have* to make changes anyway, I say we fix as  
much of it as we can and take the black magic out while we're in  
there. I shouldn't be able to stare at an object for several B5 eps  
in a row and *still* have no concept of how it works internally. It's  
time for prettifying that particular block of code. With doxygenation.

Augie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060928/3dca6f62/attachment.sig>