1) It requires its own db table instead of making use of the configs
table. This is different than we thought about for plugins but perhaps
there's no way to shoe-horn what we want into a strict no-new-db-schema
mold? itbegins, I'm curious what you guys have done in zikula for
plugins storing data since you've got a longer history and greater need
for doing this well.
Almost all our Zikula modules use their own data table - for large amounts of data it
wouldn't be practical to shoe horn it into an existing system. We do provide a
central module variables storage table, so for example you can do something like
ModuleSetVar('MyModule', 'MyName', 'MyValue'); and the obvious
extension for getting variables. These are serialized and stored in a central table, and
are good for basic configuration, but not actual data storage. A retrieval of one module
variable automatically caches all the module variables for that module, so repeated
requests don't incur the DB query penalty.
I would advise that any serious module storing its own data uses a schema of its own.
Anything else is likely to introduce unnecessary complication/indirection or problematic
performance. Having said that, I don't have much of an idea what the functionality of
the proposed plugin is, so I can't comment specifically :)