Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ddragon & cdragon support #16

Open
MingweiSamuel opened this issue Oct 16, 2019 · 7 comments
Open

Add ddragon & cdragon support #16

MingweiSamuel opened this issue Oct 16, 2019 · 7 comments
Milestone

Comments

@MingweiSamuel
Copy link
Owner

MingweiSamuel commented Oct 16, 2019

Questions:

  • Should this be a separate package? Might be an obvious answer but haven't thought about it.
  • Should it be able to retrieve splash/item/etc images (byte[] or something) or is that not useful? (hotlinking to ddragon is discouraged, but hotlinking to cdragon is fine)
  • Caching? Given that the data is static. Leaning towards no, let the user handle it.
  • Rate limiting ?
@RyadaProductions
Copy link
Contributor

RyadaProductions commented Oct 17, 2019

Should this be a separate package? Might be an obvious answer but haven't thought about it.

In my opinion we should make this a seperate package but we can still keep the code in the Camille repo. Something like: Camille.ConstantDragon, Camile.DataDragon and Camille (or Camille.RiotApi) or something along those lines. This lets consumers of the API choose what fits their needs and not have needless bloat involved that they might never use. And it won't require the whole library to be updated if we fix a bug in the CDragon implementation for example.

Should it be able to retrieve splash/item/etc images (byte[] or something) or is that not useful?

For my personal project this would be useful. But giving back an Image would make more sense, as people could then easily save it to their disk to cache it and prevent hotlinking.

Caching? Given that the data is static. Leaning towards no, let the user handle it.

I would say no, since its static data, and there doesn't seem to be a harsh rate limit on the api.

@MingweiSamuel MingweiSamuel added this to the 3.0.0 milestone Nov 5, 2019
@RyadaProductions
Copy link
Contributor

After thinking and experimenting with it, we should have the option for DataDragon to download the whole DragonTail tar from a specific patch, specified by an argument unpack it and then be able to load the json files and images through the library. So we won't rely on network IO for the most part, since its all static data anyway this will only cost roughly 1.56GB per patch due to the massive amount of images present in the DragonTail tar.
Especially since Hotlinking in general is always discouraged.

@MingweiSamuel
Copy link
Owner Author

MingweiSamuel commented Nov 5, 2019

Seems like we shouldn't reuse the Riot API regional requester, which has a lot of focus on rate limiting? So this will be a standalone lib, mainly providing DTO class generation and method-to-file/url mappings?

Similar for #24 (LCU), though rate limiting is needed there, it can just be simpler

@RyadaProductions
Copy link
Contributor

Sounds good to me

@mikaeldui
Copy link
Contributor

mikaeldui commented Jan 23, 2022

Something like: Camille.ConstantDragon, Camile.DataDragon and Camille (or Camille.RiotApi)

There are at least two different data dragons nowadays, one for League of Legends and one for Legends of Runeterra. So... Camille.LolDataDragon?

@lorenblue
Copy link

I've been looking through a few of the related issues and am just confirming.. Is this still not supported? Thanks for the info, cheers!

@MingweiSamuel
Copy link
Owner Author

@lorenblue Correct, it is not implemented

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants