Module Refactorization
The goal of this project is to add nifty features to Adium, and getting a cleaner code base at the same time. Since rewriting an open source project is a very dangerous thing, we'd like to keep the changes as small as possible, while still creating source nobody is ashamed to present as his own.
Note: This is still under development. Talk to hal2k on #adium-devl if you want to know more about it.
Summary
The_Tick asked me (am) to lead the module refactorization project of Adium. Since I don't want to handle everything manually, I set up this page to collaborate on this task.
The reasons for this project are, that some parts of Adium are ancient and need somebody to look at them. For example, some methods are underscore-prefixed, which is forbidden in Cocoa apps (reserved by Apple). Other parts are not adequate for modern protocols (like XMPP) and need to be particially rewritten.
This page lists all modules of Adium, sorted by priority. Every module needs somebody to look at it. The steps that have to be taken are listed in the next section:
Tasks for Each Module
- Look at the existing code (both headers and implementations!) and determine the issues with it (if any). Ask somebody else if something is not clearly ok or clearly broken.
- Look through the code base and see where the controller is used. It's useful to see how the API is being used in practice, since you'll need to change all of them later.
- Remember that refactoring is most likely to be successful when you are adding a feature or fixing a bug. This should be the main focus of the refactoring!
- Create a branch of the module refactorization branch in SVN for this module
- Write up an external API (a .h file most likely) if that applies to this module. This should be nearly-final before proceeding to the next step (meaning that changes are possible in a later stage, but should be avoided -- not for the cost of having unclean code afterwards though!).
- Let somebody else (preferably multiple persons) look at the API and incorporate any changes that come up.
- Ask somebody else to write up test cases (using OCUnit -- we need a separate info page for that!). These test cases should test each external API method at least once.
- Implement a stub version of the new API (maybe OCUnit can do that automatically?) and commit it to the module refactorization branch.
- If there are user interface elements, ask somebody to write up test cases (at least one for every control) using ofri's UITestingKit (when it's done).
- The main idea of UITestingKit is not to allow "dumb" testing of controls (which can already be done with existing unit tests frameworks), but to enable testing of user interaction (such as 'double clicking on an item in list x must open a window. when the new window opens it's title should be x and it should contain y,z'). Getting used to this thinking now is probably a good idea. (Ofri)
- Implement the module, either by re-using a cleaned-up version of the old code, or rewriting that part (hopefully, many parts can be re-used verbatim). If you need other modules' APIs (you will), check if there are any new APIs written for them by this procedure, and use those instead of the old ones.
- While implementing it, constantly verify your code using the test cases created earlier (don't forget the old-fashioned tests, though!)
- Re-merge the module refactorization branch to your branch.
- Fix the dependencies on your module.
- Merge the branch back into the module refactorization branch.
What's Next
- bgannin volunteered to be the guinea pig for the procedure. He'll work together with am to use it to implement the iChat importer.
- Figure out what worked and what did not, report to the other devs on the next meeting.
Modules, Sorted by Priority
If somebody wants to take over a module, please add your name. There can be multiple persons working on a single module, but those have to coordinate themselves properly.
Fell free to add modules if I forgot something!
(NOTE: The list is far from complete right now.)
iChat Importer
Owner: bgannin
Description: Guinea pig for ModuleRefactorization
Contact Controller
Owner:
Description: Handles contacts, groups and the contact list
Notes: This will probably have to be rewritten, since the meta contacts are a mess. XMPP allows multiple connections per account, which has to be considered here.
Blocking
Owner: durin42 (I'll gladly relinquish this to someone, and just work on writing test cases. I'd like to learn how to do this unit testing thing)
Description: The blocking API on AIAccount is a disaster and integrates very poorly with the contact controller. With the existing implementation, there's a lot of theoretically unneeded caching (but removing that caching causes things to break in subtle ways) and you also can end up with infinite recursion between accounts and the contact controller. This isn't technically a module on its own, but it needs to be designed sanely in several places.
XMPP
Owner: -> SoC
Description: Add new features like PEP or proper MUC.
Groupchat
Owner: -> SoC
Description: Support for IRC-style commands, esp. for IRC and XMPP-MUC. Better user interface.
Dock Controller
Owner: Catfish_Man
Description: Handles the dock icon and perhaps(?) the menu that shows up when right-clicking the dock.
Notes: This should be blocked until Leopard is out, since there appear to be some changes in that area.
Status Icon Controller
Owner:
Description:
Parental Controls
Owner: alangh
Description: Over-protective parents telling their children what to do.
Voice and Video
Owner: Everybody & nobody
Description: Might be of use for pr0n or teenagers talking to their girl/boyfriends.
Fire Importer
Owner: gbooker
