MobileRead Forums - View Single Post

kiwidude · 05-28-2011, 08:26 AM

@dwathny/charles - thx for backing me up on this and your support, very well timed as I was starting to wonder why I bother.

@charles - if you have some time to help that would be brilliant. I hadn't asked as I know like most of us you always have a backlog of stuff to do and unless it is something that has your interest I don't want to be an unnecessary diversion.

As to how you or others could help - well, as much as you are willing

. My comfort zone is making the changes to the metadata source plugins but they are as trivial to me as the custom column changes sound to you.

So - what else is there? These come to mind for now...

- defining exactly what the API will look like for the metadata plugins to define what additional fields they support. This must cater for both "Calibre known" fields, and plugin specific fields, and as you have suggested also allow defining the necessary custom column data types

- deciding what merge behaviour these fields will have if any, through the identify() phase of the sourcing. There are certainly fields which it makes no sense at all to try to merge or average. Can you think of/do we need to cater for any which should, and if so how do we define that? The easy answer may be that any such fields must be special cased as Calibre known fields in the identify() phase.

- what will the configuration screen look like, and where will it be accessed from? Is it a button placed on the metadata configuration dialog launching a separate dialog?

- what configurability will a user have for these additional fields to turn them on/off at both plugin and global level? For instance are they just appended to the existing list of checkboxes like title, author, series etc when you go to configure a plugin? What about the global settings - should these extra fields appear in the same set? Should for instance a field be listed only if a mapping exists to a custom column for it?

As examples of the sorts of additional metadata we could pull back, see the following. If you think of others on the pages that we should consider, feel free to add to this. I am sure you would agree that dealing with actual use cases will help discovering the issues we need to deal with.

Goodreads: example book
- Rating (floating point value)
- Number of ratings (int value)
- Pages (int value)
- Awards (tags or comments?)
- Other possibilities like characters, setting and original title?

B&N: example book
- Rating
- Number of ratings
- Pages
- Price (what to do about currencies, numeric or text?)

Fantastic Fiction: example book
Nothing obvious I see but others may spot something

Webscription: example book
- Price

Amazon: example book
- Rating
- Number of ratings
- Pages
- Price

Worldcat: example book
Not currently a metadata source as such, but I will add the link here for interest since you can see this page when you click on the ISBN in the book details pane. It has stuff like genres, other title, awards.

05-28-2011, 08:26 AM	#17
kiwidude Calibre Plugins Developer Posts: 4,731 Karma: 2197770 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@dwathny/charles - thx for backing me up on this and your support, very well timed as I was starting to wonder why I bother. @charles - if you have some time to help that would be brilliant. I hadn't asked as I know like most of us you always have a backlog of stuff to do and unless it is something that has your interest I don't want to be an unnecessary diversion. As to how you or others could help - well, as much as you are willing . My comfort zone is making the changes to the metadata source plugins but they are as trivial to me as the custom column changes sound to you. So - what else is there? These come to mind for now... - defining exactly what the API will look like for the metadata plugins to define what additional fields they support. This must cater for both "Calibre known" fields, and plugin specific fields, and as you have suggested also allow defining the necessary custom column data types - deciding what merge behaviour these fields will have if any, through the identify() phase of the sourcing. There are certainly fields which it makes no sense at all to try to merge or average. Can you think of/do we need to cater for any which should, and if so how do we define that? The easy answer may be that any such fields must be special cased as Calibre known fields in the identify() phase. - what will the configuration screen look like, and where will it be accessed from? Is it a button placed on the metadata configuration dialog launching a separate dialog? - what configurability will a user have for these additional fields to turn them on/off at both plugin and global level? For instance are they just appended to the existing list of checkboxes like title, author, series etc when you go to configure a plugin? What about the global settings - should these extra fields appear in the same set? Should for instance a field be listed only if a mapping exists to a custom column for it? As examples of the sorts of additional metadata we could pull back, see the following. If you think of others on the pages that we should consider, feel free to add to this. I am sure you would agree that dealing with actual use cases will help discovering the issues we need to deal with. Goodreads: example book - Rating (floating point value) - Number of ratings (int value) - Pages (int value) - Awards (tags or comments?) - Other possibilities like characters, setting and original title? B&N: example book - Rating - Number of ratings - Pages - Price (what to do about currencies, numeric or text?) Fantastic Fiction: example book Nothing obvious I see but others may spot something Webscription: example book - Price Amazon: example book - Rating - Number of ratings - Pages - Price Worldcat: example book Not currently a metadata source as such, but I will add the link here for interest since you can see this page when you click on the ISBN in the book details pane. It has stuff like genres, other title, awards.