[JiRo]

@spalda33: To už otevíráš téma, které je spíše o analytické fázi procesu paní doplňků a strategii řešení obsluhy api, spojené s možnostmi zvoleného prostředí. To poslední se týká možností použitého jazyka, v případě doplňků Kodi tedy python. Tady je každá rada drahá, v tom smyslu, že záleží, co z toho jsi schopný řešit sám a kde potřebuješ poradit. Určitě můžeš počítat s pomocí AI, a já bych se v tomto případě nebál zeptat. Ale ne, že mu popíšeš, jaký doplněk chceš a budeš čekat, že ti ho napíše (i když i tohle by asi zvládla a co vím, tak to tak hodně lidí dělá), ale že se začneš bavit právě o té analytické části problému. Nejhorší je, když si někdo nechá napsat doplněk a ani netuší, co se v něm děje a není schopen si z toho odvodil nějaké znalosti a zkušenosti a ty pak používat při další tvorbě doplňků.

Ale abych byl konkrétní, tak několik zásad (vybral jsme jen některé, bude toho určitě ještě více, ale to si už vyřiď právě třeba s pomocí AI):

• určitě nečekej, že jeden hint vyřeší vše. Je vidět, že o tom přemýšlíš, hledáš různé cesty a to je právě to podstatné, co by se v této chvíli dalo poradit. Nesoustředit se jen na jednu cestu. Použij je všechny, resp. použij ty, které ti zlepší ty parametry, o které ti jde. Což je v této chvíli rychlost.
  
• co to znamená? Hlavně to, že nebudeš hledat jednu metodu, ale zkombinuješ jich více:
  • přejít v tom procesu co možná nejrychleji na identifikaci pomocí id,
    
  • držet se myšlenky cache. Tady je možností jak to řešit hodně a je to přesně ta chvíle, kdy se AI zeptat na to, jaké možnoti, metody a nástroje řešení by ti navrhovala a požádat ji aby popsal jejich výhody, nevýhody, silné i slabé stránky a rizika...
    
  • najít point, který to hlavní kritérium (což je rychlost) ovlivní nejvíce. A to je v tomto případě jednoznačně odezva serverové služby. Jinými slovy, největší zpoždění v tomto případě dělá čekání na odpověď ze serveru. Tzn. že se v doplňku bude většinou čekat. To jednozančně vede na řešení formou asynchronních paralelních procesů. Jinými slovy, na straně tvého kódu rozdělit požadavky do skupin řešit je dílčími, asynchronními requesty.
    
  • ...
    
• nesmíš ale zapomentou na možná omezení a rizika planoucí z obecných nároků daného řešení
  • V případě TMDb APi to je například omezení četnosti requestů, takže musíš do těch asynchronních procesů zapracovat (nějak dynamicky a parametricky) i tohle kritérium, nebo budeš od serveru TMDb dostávat negativní respons (třeba 429 Too Many Requests).
    
  • někdy se stává, že soustředění na výkon vede k enormnímu zatížení CPU (i když v tomto případě to asi hrozit nebude, protože ty úlohy jsou poměrně výkonově nenáročné) a nebo velké spotřebě paměti (tady už bude teřba více přemýšlet a mít paměťovou náročnost pod kontrolou). Kodi často běží na HW, kde je sice výkon GPU ny vysoké úrovni (kvůli přehrávání videa), ale výkon CPU a velikost paměti právě na špičkové úrovni nebývá. A určitě je třeba mít i na paměti to, že Kodi velmi často běží na HW, kde se příliš nedoporučuje využívat diskové operace (flash paměti, u kterých častý zápis snižuje životnost HW), nehledě na to, že ani rychlost přístupu k této paměti také nebývá špičková.
    
• podobně je třeba přemýšlet a uvažovat i o možnostech a omezeních plynoucí z toho, že se jedná o Kodi doplněk, který musí splňovat jisté požadavky a dodržovat jistá pravidla definovaná v Kodi.
  • chování doplňku v okrajových stavech Kodi, při startu a nebo naopak při ukončování,
    
  • vhodně rozdělit úlohy v rámci doplňku
    • například rozdělit doplněk na část plugin a service a v rámci toho vyřešit vzájemnou vazbu mezi nimi
      
    • věnovat se skutečně metodě řešení asynchornních a paralelních procesů - tady je možností opravdu hodně - AsyncIO, Threading, Mutiprocessing. Tohle s sebou nese pak značnou dávku studia která metoda a pro co je nejvhodnější a otevírá to i další navazující témata:
      • např. pro jakou verzi python doplněk psát - tady bych se vykašlal na starší verze Kodi a orientoval se pouze na jeho aktuální verzi Kodi a verze python, které tato verze používá,
        
      • vybrat si pro konkrétní úlohu konkrétní metodu. Což např. pro TMDb api bude asi AsyncIO,
        
      • v rámci toho použít metody, které na jedné straně zamezí přetížení na straně sereru (chyba 429 Too Many Request), na straně druhé však minimalizují režii jednotlivě budouvaných spojení (např. aplikací Recyklace spojení a podobných metod). Tak se např. můžeš dostat do stavu, kdy odpověď pro těch 30 položek, pro které jsi ty potřeboval cca 12s, dostaneš za 1-2 sekundy.
        
      • ...
        
    • zvážit využití stávajících modulů či dalších doplňků které jsou dostupné v modulech Kodi (např. pro realizaci cache)