Replies: 3 comments 3 replies
-
|
An additional idea along with using Talkers could then mark How to go about the option(s) for the user could come down to: |
Beta Was this translation helpful? Give feedback.
-
|
So I don't want to have a has_issues attribute because if a series, whether manga, standard comics or something else, doesn't have any issues then I don't care about it, a series is a container for issues if it's empty (no issues) then there's nothing useful about it and it might as well not exist. I dare anyone to find me a completed comic with no issues or a completed manga with no chapters. If we go on the assumption that, if a series is found, it has to have at least one issue published. Then it makes this a lot simpler: we just return 1 issue when we don't have any more information and for those we shouldn't even need to return an issue number just leave it set to If I don't know how many issues a series has that is very similar to not having an issue number and trying to search, so if instead we solve that it will apply to everything, instead of making a separate option that only works in a specific edge-case.
The issue identifier definitely needs a rewrite, it's basically a giant single function masquerading as a class.
This just makes everything more complicated because now we have no separation, so when I ask for a list of series and one has an issue number and an issue id what do I do with it? Fully separating issues and series out makes much more sense because then when searching for a series there wouldn't be any issue information to make it more complicated. GenericMetadata is a random collection of any properties that would fit in any metadata scheme (not exhaustive, at least currently) and is a random combination of metadata that only applies to a series and metadata that only applies to an issue and the things that would apply to both wouldn't usually be the same if you were to fill it out accurately. Completely getting rid of GenericMetadata and just passing around a tuple of (Series, Issue) is much more likely to happen. |
Beta Was this translation helpful? Give feedback.
-
This is information source versus actual comic. The information for the series is useful (publisher, artist/writer (manga is usually one person), characters and so on). It could be argued for manga that the chapter (and to a lesser extend, volume) information is of little value. Excluding MangaUpdates, Anilist, MyAnimeList (it has manga too) does not (currently) seem ideal. (Kitsu may be the general answer but may never have the coverage of MU/MAL.) The question is: How can MU (et al) be included with CT?
That seems like a bad idea as the extra information (publication date, synopsis, characters, etc.) can all be wrong. An option such as
The separation comes from the function. A series function only looks for series data. It could be in
As to getting rid of GenericMetadata. At some point |
Beta Was this translation helpful? Give feedback.
-
If it's wrong, then why is it being returned? I don't want to just arbitrarily apply all series information to a comic, that's not a great idea and it is not what is currently done. Currently we query a source by providing it inputs and then applying what it returns, the only check anywhere is the series name when searching, for 2 reasons:
CT assumes whatever is returned from a talker is correct, if it return multiple results (specifically for the series) we let the user decide which result to use. CT doesn't technically make any other decisions about the metadata that is returned.
We already have an algorithm in place to preserve metadata from any given source and it works well. I don't see why it needs to change.
How about we amend this:
Lets do an over explained example:
We can modify this slightly for auto-tagging:
|
Beta Was this translation helpful? Give feedback.
-
|
In terms of paths for the new
^ This I believe would require a new function added to |
Beta Was this translation helpful? Give feedback.
-
|
Trying to figure out implementation is never going to work until we know what we want it to look like. First what information does metron_talker, gcd_talker or any other plugin want that it currently doesn't get, or does not get in an optimal way? Second what information do any of these plugins have to provide that it is not able to or isn't able to in an optimal way? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I believe one of the main problems with supporting series only talkers and to cover #234 is that
iidoes a joint series and issue search and identification. I propose splitting theseriesandissueparts and also removeComicSeriesand useGenericMetadatafor both series and issue internally.I know you've been against a
hasIssuestalker variable before andiinot needing to know but for the issue window and tagging without an issue number etc., I'm not sure how it's possible without some indication of capability from the talker.With this knowledge (and an option to cover #234)
iicould operate with series only talkers. It would still be a requirement that an issue talker needs an issue number.How does that sound?
Beta Was this translation helpful? Give feedback.
All reactions