While we were discussing a generic I/O layer in MariaDB, Sergei brought up the issue of WL#3859. This worklog carries a principal issue that I wanted to mention and discuss. Sergei, if I understood you correctly, you said that Sun MySQL would never take a new internal API that does not follow the WL#3859 framework. Correct? My understanding (which may or may not be correct) is that at least part of MySQL/Sun wants to develop the storage engine plugin layer (and all other plugin layers) to be a complete ABI, that is complete binary compatibility. So that the user can obtain a pre-compiled plugin independently and load it into the server without risk of crashing if plugin is compiled against a different source version of the server (but may get an error message if versions are incompatible). This basically means that all data and code needs to be exported via the WL#3859 framework, not using the system linker as is currently done. Advantages include - Avoiding crash on incompatible version is good. - Supports selling proprietary (non Open Source) plugins. - Works on Windows where the system linker cannot export symbols from executables (though there is a standard workaround of just compiling the server into a library that is called from a stub main executable). Disadvantages include - Supports selling proprietary (non Open Source) plugins (yes, can be an advantage or disadvantage depending on point-of-view ;-). - Will tend to discourage making desirable changes, as the procedure becomes more complicated (more work to track versioned API, less flexibitily in what C++ language constructs can be used); and there will be the desire to minimize binary incompatibility. It would be great if some of you still inside Sun could confirm or reject that this is the way things are. This raises at least two important questions for MariaDB: 1. Do we want to adopt this direction, moving all existing exposed server internals into this framework, and implementing any new ones within it as well? Or reserve the right to use old-style direct linking where it makes more sense? (We can of course in any case use the WL#3859 framework where it makes sense, the issue is the principle of using it for everything eventually). 2. It seems impossible that we can keep the Sun/MySQL API versions and the MariaDB API versions 100% synchronised. So how will we handle version compatibility (ie. Sun/MySQL version 0x0109 may be different from Maria version 0x0109 due to different paces of development)? Will all plugins need to track two different versions, one for Sun/MySQL and one for MariaDB? Or will we somehow coordinate between the two teams to avoid version conflicts? Any opinions? My personal opinion is that I am sceptical if this worklog is a good idea; most of the big projects of this kind that have been successful have used the old MySQL approach (Apache, Perl, the Linux kernel). Though I'm not 100% decided one way or the other yet. But more importantly I think we need to have a conscious decision on how to deal with this in MariaDB, as it is a fundamental design issue that will impact many other desicions along the way. - Kristian.