|
I am starting from the point of ignorance: I don't know where downloaded metadata is written to the db. I assume that it all ends up at some point at library2.set_metadata.
There are two issues to solve, I think. The first is to have a common set of names for diverse and extra metadata. For example, various editions of books have different page counts that might be called 'pages' or 'length'. Authors in multi-authored books sometimes are contributors, sometimes are authors. Plugins should be able to query and add to this set of names.
The second problem is mapping the data to columns in the database. Here I am in agreement with Kovid -- this is best done as a mapping of metadata name to column. Set_metadata can implement this mapping. The only complexity I see is handling multiples: should values be merged or should they replace?
One way to proceed is to have a dialog in preferences that defines the names the user wishes to use. The set to choose from could come from the installed plugins (this is a push system), or the plugins could use these names (a pull system). Both have merit. The user would choose what column to use for storing information under the name, and if necessary any auxiliary information such as merging.
Both push and pull systems should permit specifying a data type for a name. The dialog would use this to prevent absurdities such as assigning a text comments field to an integer. Some special cases could be allowed, such as series-type fields carrying along the series index (somehow).
Bottom line: as far as I can see, the major problem is having an extensible set of names with known semantics. Once we have these, mapping the names to columns (custom or otherwise) is not hard.
|