milky: To speed up things, we could reimplement some plugins, using SQL queries instead of ewiki_database(). This would make sense to take advantage of more advanced database functions.

Advanced means also using the anydb_query() interface, and not coding the SQL commands for compatiblity with the outdated MySQL (when the optimized plugins work with MySQL in accident, that would be ok however).

So a plugins/sql/ would make sense for:

• another search plugin
• some admin plugins
• link structure anylizing plugins (backlinks, page trees)
• inclusion of non-wiki parts
  • a really separate forum package with its own table?
  • an interwiki (remote pages) database
  • visitor, referrer loging (i don't need it, but citizens demand for...)

anydb_() vs. mysql_()

It is currently still possible to use MySQL with the anydb interface, but this may eventually change, if we enhance the anydb plugin to take advantage of all other SQL databases enhancements (MySQL isn't even SQL92 entry).

But because there aren't that much ewiki_database() functions, there is little need to break compatiblity. Instead we could replace ewiki_database_mysql() in the "ewiki.php" script with the one from the anydb plugin. So we had one unified SQL database interface, besides our ewiki_database() interface. anydb_() isn't slower than using the mysql_() functions directly.

So, is it worth to take that code overhead in the core script (around +15K)? What's your vote?