Hi, Antony!
On Apr 04, Antony Dovgal wrote:
> On 04.04.2009 00:15, Konstantin Osipov wrote:
> > * Antony Dovgal <tony@stripped> [09/04/03 18:53]:
> >> > Opening up the class headers means you are creating a pact
> >> > between you and your developer base. You are saying "this is an
> >> > API, we promise to inform you of changes, and to not make them
> >> > lightly". Is this where the MySQL codebase is today?
> >> I'm definitely not the right person to answer such questions.
> >
> > Well, it isn't. And this is why there is hesitation with going
> > forward with your "lazy" approach.
>
> The point is that my 'lazy' (I agree with the term) approach does not
> open any server API - *it's already open*.
It's not really an API, in the sense that we never committed to
maintaining it. A real API is a contract between the API developers (us)
and API users (you). Current storage engine "API" is not (and never was)
a contract. It's more like a peek into ever-changing server internals.
> In order to build a plugin I need full MySQL sources, which means I
> already have access to all the headers and private structs. And if my
> plugin uses some private server struct, you can't change the struct
> without breaking the plugin - this is the current situation and my
> patch doesn't change it in any way.
Yes. This is the current situation and your patch doesn't change it. But
it changes the perception of it - it makes server internals easier to
access.
Look at it this way - a plugin will always be able to access server
internals. Even if we will completely hide all definitions (it's not
difficult to make .h files practically impossible to include outside of
the server sources) a plugin author can simply copy the relevant
definition to plugin sources, grab the address somewhere in the server
and dereference it. We can never prevent it, as a plugin is executed in
the server address space. But by explicitly providing the definitions
we're saying "Here, you can access these structures and classes. If you
hack around to access anything else - we know that you can do that -
you're on your own. No guarantees that it'll work in the next version,
no support that it'll work at all. Whatever happens - it's all your
fault."
Basically, this is why installing the internal headers is not a good
idea. By installing them their perception changes from "Here be dragons"
to "Here, we've created it for you to use".
> The patch addresses another problem - I need to configure the sources
> using the same options that were used for MySQL server.
>
> This isn't a problem when you build both plugin and server from
> sources, but what if the server was installed from RPM? Can I install
> appropriate -devel package with headers and be sure that my plugin
> will compile and work ok? Nope, I still have to have the sources and
> make sure I ./configure in the right way.
> This is what I'm trying to fix.
Let's take these problems separately.
To configure the right way - can you use mysql_config for this ?
Regards / Mit vielen GrЭъen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB MЭnchen 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
GeschДftsfЭhrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin HДring
