Add My Drama List API

[qubist-pixel-ux]

closes #14

• This pr uses unofficial API because MyDramaList requires sending an email and specifying the title/app name to get API key. Users might not have App Name/Title. Plus it is very troublesome. (My Drama List API Request Page)
• The unofficial API scrapes pages on the fly and responds to queries.
• The API is hosted on vercel. Depending on vercel tier, it might become unavailable after too many requests and might cause bugs.
• If a secure method to store api key is available, then it might be possible to use single developer API key for all users since the limit is very high.
• Getting Official API key takes time. It has been many days since I requested the key. So unofficial API is the way to go.

Pending Tasks :

• Handle additional data
  • There is a lot of relevant data that cannot be included in the current movie and series modals. eg : Country, Tags, Rank, Popularity, etc
• Properly format runtime/duration
  • The runtime/duration is currently specified as 1 hr. 47 min. Convert this to duration datatype of dataview plugin 6hr7min
• Update Readme (After all tasks completed)

Sample API Response :

Search : https://kuryana.vercel.app/search/q/space%20sweepers
Movie : https://kuryana.vercel.app/id/695815-blacklisted
TV : https://kuryana.vercel.app/id/6741-running-man

[qubist-pixel-ux]

Should I extend the movie and series type to handle the additional data ? We can create two new types, "Asian Movies" and "Asian Shows" to handle the additional date.

Or I can just add more fields to existing media types.

[qubist-pixel-ux]

All pending tasks have been completed. PR is ready for review and merge. If possible, create a new release after merging.

[qubist-pixel-ux]

Any update on this PR ?

[mProjectsCode]

From a quick glance this seems good, though I am not sure about all those extra properties for the MovieModel. My personal guidelines for adding new properties to the models has been to only add them when they are available in multiple APIs, as the data format and "completeness" should be consistent across APIs.

[qubist-pixel-ux]

From a quick glance this seems good, though I am not sure about all those extra properties for the MovieModel. My personal guidelines for adding new properties to the models has been to only add them when they are available in multiple APIs, as the data format and "completeness" should be consistent across APIs.

I vaguely remember many of these fields present in omdb. They are not read by OMDB API though.

If I were to remove those extra properties from MovieModel, where would I add them ?

[qubist-pixel-ux]

Pinging the PR again.

[mProjectsCode]

I'm sorry. I currently don't have much time to review this. I will get to it when I find some time.

[mProjectsCode]

If I were to remove those extra properties from MovieModel, where would I add them ?

I would remove them since one goal of the plugin is a consistent data format across all APIs.

[qubist-pixel-ux]

If I were to remove those extra properties from MovieModel, where would I add them ?

I would remove them since one goal of the plugin is a consistent data format across all APIs.

How should I add the data then ? I don't think we should remove that data since I use it to search. The data is relevant.

[ltctceplrm]

If you really need every single bit of that data and still want to use the plugin then you could make a templater template to grab the extra fields and add them automatically after the note is created.

Otherwise if I might give my opinion about the extra fields:

1. nativeTitle and aliases can be seen as the same thing, on top of that series already have title and englishTitle so instead a potential solution would be to have nativeTitle, aliases and englishTitle be merged into alias (rather than aliases since obsidian uses alias). Then you'd just have title and alias with all the potential other title
2. mediaTags and genres are pretty similar and you could again just merge those
3. votes, ranked, popularity, watchers don't seem useful so I would skip those
4. country is actually a useful field imho and omdbAPI also has it.
5. content_rating could also be useful and has been requested before ( Add ratings (e.g. R, PG13, etc.) #75). Though it would be contentRating to keep the same style as the other fields. omdbAPI also has it.

[qubist-pixel-ux]

If you really need every single bit of that data and still want to use the plugin then you could make a templater template to grab the extra fields and add them automatically after the note is created.

This is something that should be done automatically by the plugin, that's why we use the plugin in the first place.

Otherwise if I might give my opinion about the extra fields:

1. nativeTitle and aliases can be seen as the same thing, on top of that series already have title and englishTitle so instead a potential solution would be to have nativeTitle, aliases and englishTitle be merged into alias (rather than aliases since obsidian uses alias). Then you'd just have title and alias with all the potential other title

Yes, all three can be merged.

2. mediaTags and genres are pretty similar and you could again just merge those

Yes, those two can be merged too.

3. votes, ranked, popularity, watchers don't seem useful so I would skip those

Those are actually very useful to find what to watch next. User can run dataview queries to find what is most popular in their watch list. I do it all the time on website.

4. country is actually a useful field imho and omdbAPI also has it.

Let's add Country with this pr.

5. content_rating could also be useful and has been requested before ( Add ratings (e.g. R, PG13, etc.) #75). Though it would be contentRating to keep the same style as the other fields.

I'll edit it to be contentRating.

I do think all data should be retained. Just because the plugin is trying to have consistent data format across all APIs, it does not mean it should not try to save all the data.

[ltctceplrm]

This is something that should be done automatically by the plugin, that's why we use the plugin in the first place.

Well the plugin has a lot of users who might all want slightly different things from the plugin so it's not possible to cater to everyone, personally I do like the consistency between the various APIs and media types.

I understand your desire to add all of the info but I feel there have to be some compromises.

As a side note templater would scrape the info automatically and work with mediadb if you modify a scraper templater script like here

[qubist-pixel-ux]

This is something that should be done automatically by the plugin, that's why we use the plugin in the first place.

Well the plugin has a lot of users who might all want slightly different things from the plugin so it's not possible to cater to everyone, personally I do like the consistency between the various APIs and media types.

But consistency should not be equal to less data. Maybe we can have a new setting so user can select which fields to include, maybe per API ?

I understand your desire to add all of the info but I feel there have to be some compromises.

As a side note templater would scrape the info automatically and work with mediadb if you modify a scraper templater script like here

Okay. But maybe we can find a way to add these information in plugin itself ?

[ltctceplrm]

But consistency should not be equal to less data. Maybe we can have a new setting so user can select which fields to include, maybe per API ?

This is actually already possible, though instead of per API you can remap or remove specific fields per media type

But maybe we can find a way to add these information in plugin itself ?

In that case you'll have to wait for mProjectsCode to have more time and review the proposed changes to see if he agrees or not.

[mProjectsCode]

Please resolve the merge conflicts.