Closed motyc closed 5 years ago
Nedaří se mi stále použít a struktura zůstala stejná.
Ano, zapomněl jsem na to - nicméně už se pracuje na zahrnutí datumu (čas podle mně není žádoucí - exporty jsou jednou denně, takže klient dostane ta samá data ráno jako večer) a nahrazení lomítek tečkami...
No, ale aktualizace se neděje o půlnoci... Záleží samozřejmě, jak to budeme interpretovat, možná to nevadí.
Ano - den který se dává do resumption tokenu není nutně momentální den, ale nastaví se na serveru na momentální den poté co skončí export (a konverze do RDF) pro každý den. Takže když klient začne vypisovat záznamy třeba v pondělí 5 minut před půlnocí, dostane resumption token s pondělním datem, a může ho používat celé úterý (a chvilku ve středu, než se před středečním exportem pondělní soubory smažou). Ten samý token (a ta samá data) se použijí pro dotaz v úterý 5 minut po půlnoci, kdy ještě není hotový úterní export.
A asi bysme opravdu měli nastavovat resumptionToken expirationDate (když ho fakticky máme, řekněme na vteřinu po půlnoci), nicméně to dosud není implementováno.
A nemělo by to být spíše na čas, kdy se dělá nový export? To je půlnoc nebo kdy? Pokud ano, pak souhlas...
S výjimkou "expirationDate" ok.
1) byl bych pro, abychom v resumptionToken nepoužívali speciální znaky, zjednoduší se tak případná implementace pro harvestery, protože je nebudou muset escapovat
2) myslím, že resumptionToken by měl být nějak unikátní v rámci dané verze exportu, tj. asi by bylo dobré, aby obsahoval např. datum a čas, aby se nemohlo stát, že jej použijí druhý den a dostanu nekonzistentní výsledky; když v něm bude datum a čas + nějaký řetězec, nebude zaměnitelný
3) v souvislosti s předchozím bych nastavil pro tokeny expiraci na dobu těsně před novým exportem XML a indexací pro API (nějak aby to na sebe logicky navazovalo)