Ace3 is an addon framework for World of Warcraft to make writing addons easier -- the official evolution of Ace2. The primary difference from Ace2 is to be more interoperable with as many frameworks as possible, allowing only bits and pieces to be chosen for addons, and no longer be a one megabyte monster. In other words, you need not have multiple libraries to use the functions of only one library, and need not find yourself using only a few functions from a big library. The idea is for independent libraries that can even work with addons using libraries from other frameworks as well.
The development is done by the Ace3 Development Team, which contains multiple seasoned coders and testers.
More information to come as development continues.
The team thinks that Ace2 had strayed too far from what it was originally built to do - a framework which provided developers the essential part of the addon.
By the word 'essential', it means if one of the Ace3 libraries is included in an addon, then most, if not all, functionality of the library will be used. In other words, the library is used to avoid code duplication and gives a quicker foundation to an addon.
In contrast to the current Ace2, Ace3 is NOT supposed to be:
- A "standard" which all authors must follow in order for their addon to work with Ace3.
- A complete abstract layer which does all the jobs authors may think convenient.
- Help dumb users to use their addon easier.
- Help dumb authors to write addon without knowing how it works.
In short, what Ace3 IS supposed to be:
- A simple framework offering essential functionality nearly every addon uses
- Abstract libraries for very specific tasks, mainly usable without any hard dependencies (framework-agnostic)
- All libraries limited to their original purpose, no extra payload you might not want/use
Read more for reference:
What about efficiency?
Ace3 is designed for minimal overhead when embedding in even a single addon, not a huge universal standard which all addons must follow in order to save memory/CPU.
The philosophy of Ace3 is very close to Dongle, which is another framework targeted at minimal overhead of embedding. This is what Dongle was very successful at, in the sense that most users don't even know they're using a Dongle-based addon.
With this in mind, ideally you're not supposed to lose efficiency even when you only have one Ace3 addon running in WoW. Also, with the goal of small focused libraries, the amount of "dead code" (library features not used by the addon in which the library is embedded) should be kept to a minimum. If addons are only loading the code which is essential to their operation, the user should not notice a significant increase in load time when using many embed libraries. This should (hopefully) reduce the need to run "standalone" versions of the smaller core libraries. Simply put, users won't be loading 250 copies of library code used in one 3 of those addons.
As for code efficiency, we have gone to painstaking lengths to make sure that any and all code run in critical paths contains as little extra fluff as possible, and try our damndest to squeeze the extra % out of switching if tests around and whatnot. We're very good friends with os.clock() loops now.
How are libraries handled now?
For non-core libraries, most authors have agreed that libraries should be made independent of any framework. LibStub was then created, a universal library stub, which any author can use. Even the authors of auctioneer and some famous individual authors have decided to use this.
So when anyone wants to design a LibStub based library, it should be made independent of any framework, if everyone can follow such a simple idea, then ideally we hope that whatever framework an author choses to use, it makes the author's life easier, while framework-independent libraries centralizes processing and provides a more efficient WoW UI environment.
And yes there are shared tasks that may or may not have to be duplicated in a library. One such task is management of callbacks. In this case, several Ace3 libraries use a minimalistic "CallbackHandler" library which they all embed. But yet it does not introduce a depedency on bigger core libraries (such as AceEvent). For other simple tasks (handling events, doing onupdate calls), the overhead of just writing your own handler for the library is so small that having the library dependency-free clearly outweighs any other gains.
AddOns although no longer need to set "OptionalDeps: Ace3" or "X-Embeds: Ace3". Since Ace3 is so tiny, our package generation script will keep it inside the package, even in no-ext mode. We greatly discourage the use of a standalone Ace3, because we specifically designed Ace3 to work perfectly fine in embedded mode. There is no noticeable improvement when running Ace3 dis embedded, in most cases it might even be slower, because the standalone Ace3 includes additional debug and maintenance code.
How can you help in the development of Ace3?
Head to Jira, sign up and make comment. Raise any issues you can come up with there, and the core dev team will clarify anything they can.
If you have a great idea to improve upon aspects of Ace3 don't hesitate to produce some code and comparison tests.
Who is running this Dog and Pony show?
- Kaelten is the current lead and arbiter and also rewrote AceHook for Ace3
- Ammo is the evil spokesman and wrote AceAddon
- Nevcairiel is the Official Dresser and Make-up artist and handles AceDB (with credits to Cladhaire for initial implementation)
- Mikk likes hashing out raw code for new ideas and sleeping in, and stands to blame for AceConfig (except AceConfigDialog), CallbackHandler, AceEvent, AceTimer, AceSerializer, AceComm, AceConsole
- hyperactiveChipmunk leads the legions of amusingly-attired rodents on unicycles and ported his AceTab to Ace3
- Nargiddley is the king of UI and wrote AceGUI and AceConfigDialog
- Tekkub is the performing bear
- I prefer "Master of fuzzy artistic eroticism"
Early testers and co-designers include:
- Andreasg (yay for the agUF Ace3 port), Antiarc, Cladhaire, Elkano, Pastamancer, Tekkub, Wobin