>
> I am not sure yet how the implementation in case of virtual tables
> fits into the overall picture of "pluggability".
Yeah, it was a goal of the design to make writing new types as easy as
possible, so having to wire up a new vtable for each new event type works
against that.
I'd be inclined to start with just two tables: one "diagnostic_events" that
lists all events, and another "diagnostic_service" which lists what's
enabled (and allows you to enable them live). With the design of
Diagnostic Events as subscribe and pull, it would make sense (to me) if
enabling an event class in the diagnostic_service table ('update
diagnostic_service set enabled = true where class = '<event_name>') then
also does a subscribesAll with a noop consumer.
Extending/configuring the limit makes sense as part of the binlog
implementation. I'm hesitant about allowing users to increase the in-memory
store.
