maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

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.