Open MingweiSamuel opened 4 years ago
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.
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.
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
Sounds good to me
Something like:
Camille.ConstantDragon
,Camile.DataDragon
andCamille
(orCamille.RiotApi
)
There are at least two different data dragons nowadays, one for League of Legends and one for Legends of Runeterra. So... Camille.LolDataDragon
?
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!
@lorenblue Correct, it is not implemented
https://cdn.communitydragon.org/latest/champion/Zyra/data (seems cdragon only is en_US)
Questions:
byte[]
or something) or is that not useful? (hotlinking to ddragon is discouraged, but hotlinking to cdragon is fine)