As part of the "pluggable" architecture, MySQL should take existing code and make it available as libraries that can be used by developers of storage engines and other plugins. Today it is easy to create a trivial storage engine, but rather daunting to build one that, e.g., caches disk pages in memory or uses B-Tree indexes. So possible candidate libraries include MyISAM's key buffer and a B-Tree implementations. Both of these can be found in the mysys/ directory, so they are already good candidates to be libraries, but they aren't really usable yet. Most notably, they aren't formally documented. This task has a few major components. 1: Any candidate library code must become independent of its current context. The library cannot assume that it is running in any particular engine, and the server cannot assume that only one engine is using a library. 2: Each engine or plugin that uses a library needs a way, independent of any other engines using it, to configure it (e.g. "Key_buffer_size") and for it to report status and statistics (e.g. "Key_reads" and "Key_read_requests"). Perhaps this means that we need global "configuration" and "reporting" APIs. 3: The library code must be documented for programmers. We should publish a manual that contains both a reference to the APIs and examples that use them. This may be the biggest part of the task. The "functions in the mysys library" page of the internals manual is a bare-bones beginning to this. 4: The existing storage engines need to be maintained in a way that adheres to the published APIs. Once published, the documentation must be a "living document" used both internally and externally or it will cease to be useful. Every public API (including these libraries, but also especially including the handler, UDF, and plugin APIs) should be given a version number and assigned to a particular developer who manages and maintains it.