Support Generating Reading Lists

[rad96]

Add a special community driven reading lists
An idea that a site user can make a list from whatever issues he found appropriate under some theme of his choice

Example:
"Marvel chronology 1976 - 1980" - contains issues
"Spider-Man chronological reading list" - contains all spider-man related issues in chronological order

Nice feature to have - is "likes" or "favorites" for them, so you can sort out based on amount of likes

And to have an ability to download this as CBL file, so you can import it into Kavita or Komga

P.S. Currently there is github repo with CBL files for various stuff - https://github.com/DieselTech/CBL-ReadingLists/
But issue is - with any change on database itself, like change of series name, or any cover years update, this CBL simply stops matching, it's not valid after that.
So it would be so good to have that stuff on database side, so database itself will be able to generate and regenerate that files for you.

[bpepple]

I looked at CBL's awhile back, and it's got some serious flaws (no clear shema definition, it's fragility with names, etc) and so I'm not inclined to add an exporting to CBL feature, but I think a better solution is to provide the necessary information thru the API. That way it would be simple for a user to write a program to spit out the data in CBL format (or ideally a better format).

What information to include in the API call and parameters to filter by, would need to be defined, but that is something that shouldn't be too hard. I know Jo was looking into CBL's recently, so he may be able to help define the requirements.

I've thought about adding the ability to rate issues (#48), most likely using some like django-star-ratings, which might work for your wish feature aspect.

[rad96]

I looked at CBL's awhile back, and it's got some serious flaws (no clear shema definition, it's fragility with names, etc) and so I'm not inclined to add an exporting to CBL feature, but I think a better solution is to provide the necessary information thru the API. That way it would be simple for a user to write a program to spit out the data in CBL format (or ideally a better format).

What information to include in the API call and parameters to filter by, would need to be defined, but that is something that shouldn't be too hard. I know Jo was looking into CBL's recently, so he may be able to help define the requirements.

I've thought about adding the ability to rate issues (#48), most likely using some like django-star-ratings, which might work for your wish feature aspect.

Yes, my mention of CBL was just an example of applicability of that feature
I think if there will be some API endpoint which will return "Reading list" in some format there would be no problem to generate whatever CBL or any file user might like 🤔

[bpepple]

So, got some information on what the new CBL would require something like this from the Issue (list) model:

{
  "id": 0,
  "series": {
    "id": 0,
    "name": "string",
    "volume": 32767,
    "year_began": 32767,
    "cv_id": 1234568,
  },
  "cover_date": "2024-11-17",
  "cv_id": 2147483647,
}

We would most likely have a decent amount of parameter (ids, names, etc) for the different resources (character, teams, etc) in addition to filtering by cover dates, so the user could generate lists based on their criteria.

One thing the schema has that Metron doesn't (but might be a decent idea to implement) is associating story arcs. If I get some free time I might look into this a bit more.

The one problem I see is the that the json-cbl-standard requires a series id, which is a problem when using multiple sources due to inconsistencies between the different services. So there isn't a 1-to-1 linking between the services for series.

For example, Comic Vine has the series as X-Men: Black Sun but Metron and GCD has them as separate series (based on the issues indicia).

Now there are solutions for this, but none of them are that great:

1. For services (Metron) that track the id's between services is to make sure the DB field is set-up to accept duplicate values for series. So, using the example given above, in Metron all the series would have the same CV_ID. Not great, but semi-workable for cases like above. Unfortunately, you've also got a problem where issues for a long running series that restart numbering, I'm thinking something like Amazing Spider-Man, where the original series was cancelled, then another series started and then partially thru the run they revert to original number. Depending on the service they could associate the issue to the original series, so again there's not a 1-to-1 linking between them. In that case, there isn't really a solution to resolve that.
2. Modify the json-cbl-standard to make the series id optional. I'd be interested to know how consumers of the spec are using that information.

[rad96]

First of all - I don't think that Metron, if Metron will generate CBLs, should care about GCD or Comicvine
It's nice to have, but I don't see for what, if there is not much ways to work around it

Also, Metron have different naming for couple of series (I remember matching some to CV manually), which also I see as a problem

[bpepple]

First of all - I don't think that Metron, if Metron will generate CBLs, should care about GCD or Comicvine It's nice to have, but I don't see for what, if there is not much ways to work around it

Agreed. I just wonder what use the series id would be to the consumers of their json. Having the issue id should be sufficient for almost any use-case I can think of off the top of my head.

Also, Metron have different naming for couple of series (I remember matching some to CV manually), which also I see as a problem

ComicVine, by far of all the services, is the worst in regard to series naming. I'm mean just this last week they used X-O Manowar: Resurgence, instead of following the indicia data of "Resurgence: X-O Manowar".