|
Thx Kovid. I guess the answer to that is a question of how "intrusive" this additional functionality should be on the Calibre API. You say the consumer of the identify() function - but that will need to be back on the GUI thread well out of the metadata sourcing function right?
I guess what I had in mind would have kept the metadata plugins self sufficient. So the result of identify() is a Metadata object that is ready to be persisted. The configuration of the mapping and the applying would be plugin specific - the good being that the rest of Calibre doesn't care, the bad being duplication of configuration screens etc per plugin (plus the technical issues of no db object to have the column definitions).
If I instead defer that mapping, how would I know what mappings to apply? Or does the "map this field if it exists to this custom column name" become a generic configuration of Calibre's metadata downloading, in a similar way to how you globally set things like max number of tags, swap author names etc? That would reduce the configuration duplication, but you would have the problem of knowing the list of possible "extra fields" the user could map (unless you extended the API to allow each plugin to define a set of additional fields and iterated across the plugins). And you would still need to apply that mapping presumably right at the last moment possible when you know you are back with a db available again...
Or I could be off base of course :-)
|