History: OneOfManyAPI

If you want to understand what I am doing here first read MoseCoreDump. Do not confuse an API with what is being talked about here as the core. The whole point of an API is that it sits between functionality and the core.

Advantages:

• New functionality is easier to write/integrate, particularly for those who are integrating software they know well (because they know what to chage in that code) but do not know TikiWiki very well (because they don't have to go searching for the way to deal with things like users, databases, permissions etc.).
• New core functionality (eg LDAP authentication) is easier to write because you know what the requirements are - to serve the API functions. You don't have to worry about
• It becomes possible to migrate the core incrementally without breaking functionality. Once you are sure that nothing outside the core accesses, for instance, users other than through API functions, you can completely refactor the core to improve performance, maintainability, compatibility etc. - or even to replace the core completely by integrating TikiWiki into an existing system that provides those core functions.

The table below shows the relationship between elements of the system viewed as layers. Each layer is dependent only on the layer directly below it, therefore in order to manage change, only the interface between adjacent layers need be considered.

Presentation Layer	Templates, CSS
Logic Layer	Functionality
Interface Layer	API
Core Layer	Users	Groups	Permissions	Request<br />Authentication	Database <br />Abstraction	Configuration	etc...
Data Layer	Database, file system data, external data sources