[Adium-devl] Great renaming timeline?

[Colin Barrett]

On Sep 16, 2007, at 8:31 PM, Evan Schoenberg wrote:

>
> On Sep 16, 2007, at 10:59 PM, Chris Forsythe wrote:
>
>> 	The GreatRenamingOf2007 wiki page states that it's preferable to get
>> this done as quickly as possible. Might I suggest that, instead of
>> the normal meeting this Thursday, we start it then? Everyone should
>> have a bit of time blocked out for the meeting anyhow, so that might
>> make this a good starting point. This would give us Thursday - Sunday
>> to catch any issues with it.
>
> Beginning a Great Renaming without being 100% sure of what we want to
> rename and how isn't going to work.  Let's discuss.

Excellent, I was just about to start a thread about all of this, and  
it's already done!

> Some thoughts:
>
> 1) Naming
>  * AIU* for AIUtilities seems reasonable.
>  * How about AI* for AdIum framework, and simply Adium* for internal
> non-framework classes, excepting where some other naming is more
> informative (such as Purple* for the Purple Adium Service).

This sounds fine to me, I actually came up with the idea and put it on  
the wiki page just a couple minutes, before reading this thread. Weird!

So, are there any objections to

Adium.framework => AI
PurplePlugin => Purple
AIUtilities => AIU
Everything else => Adium

?

Lets put the item on the meeting agenda and have a last call there.

> 3) Ramifications
>  * This will probably break every existing compiled plugin.  That's
> just as well, but perhaps we should have a plugin API to propose
> alongside saying, "Every plugin must be recompiled to work".

I think this is OK. There is no real plugin API before this, and our  
version numbers have no real significance to plugin authors.

At some point we need to come up with a plan re: Plugins and API  
stability, yes, but I'm not sure right now is the time to do it.

Be warned: Binary-level compat really is a commitment not to change a  
specific set of interfaces. At all.

I'm not really sure Adium's abstracted enough that this will prove  
more of a benefit than a hindrance. (We are quite loosely coupled,  
yes, but there is not much abstraction to hide behind when you want to  
change implementation details or clean things up).

-Colin