← Back to team overview

maria-developers team mailing list archive



To me both approaches are like indistingushable. The 'service' is too just
the set of callback methods.
I don't know if we should keep that 'plugin type' specification or not,
the very idea is getting server's data and sending commands
to server using the callback functions.
That way plugins get free from the API versions, and the server
is free from fixed structures to send/get data to/from the plugin.

If we need we can limit the access to the 'audit service' to only these
plugins registered with the AUDIT type. There will be other limitations
anyway. The server data can be accessible in some context
inside the audit_notify functions for example)
but not accessible in another.

Best regards.

23.10.2016 15:55, Sergei Golubchik wrote:
Hi, Alexey!

On Oct 23, Alexey Botchkov wrote:
Hi, Sergei.

I'd like to draw your attention to this old issue:

The idea was to make a bigger thing - to modify the plugin API
so it is easier to use and let user to do more. Particularly to
notify warnings to the audit plugins for this 7389 task.
That was done with this task: https://jira.mariadb.org/browse/MDEV-5313

Just to refresh our memory:
I proposed to get rid off the API versions and version-dependent
memory structures that are used to transfer data to and from the plugin.
All we need to do is adding new 'audit_plugin_service'. Which is
just the normal service that offer methods to the auditing plugin to
send commands to the server and get the server data. You can look at the
patch http://lists.askmonty.org/pipermail/commits/2016-February/009025.html

So, Serg, do you have anything to say on that subject?

First, I'll say that I'm sorry for not replying earlier :)

Now, "service" is a server functionality provided openly to all
plugins. Kind of a utility library, like alloc() or printf().

Moving audit to a service, means there is no longer audit plugin type
(we won't remove it, but it becomes useless) because any plugin can use
audit functionality. Is that what we want? Audit is not a
general-purpose thing. May be you mean that we should deprecate all
plugin types and move everything to services (not now, but over time)?
That one possible approach. But just moving audit to a service is not
very logical.

Another approach would be to keep audit plugin as a *type*, but still
use your callback approach. That's fine, callbacks don't need to be done
via services, there are plugin-type-specific callbacks too.
In that case an audit plugin will get some kind of an audit handler from
the server, and will invoke its audit methods, for example



Chief Architect MariaDB
and security@xxxxxxxxxxx

Follow ups