|
IMO allowing the plugins to enumerate their extra fields and having a global config will be both easier to program and easier to use. The config for this could then simply have a plugboard type mapping of fields to columns. This also has the advantage of allowing per library settings.
Logically speaking, the job of mapping fields to columns cannot be done by the download infrastructure. The download infrastructure is designed to run in a context that has no db, for example, via the fetch-ebook-metadata cmdline tool.
The only downside is that plugin authors will have to be careful to use the same field names for the same information, but that shouldn't be too hard. We can add comments to the base class enumerating the more common "extra" fields.
EDIT: The only major problem I see is that the extra fields will have no semantics associated with them, so it will be hard to design code to pick the best one. I would suggest have a set of "standard" extra fields that the base class knows about and can merge intelligently.
|