cache ve flashi

mrZ
vzdy se to resi stejnym zpusobem - za url, kterou nacita flash pridas ?+random number -> generujes url napr.

"neco/souboe.xml?1836"

Je to takove pseudo get. Timto oklames cache, protoze browser si mysli, ze se pokazde nacita jiny soubor.

Takto se resi cache jak na samotny swf soubor (nactes hlavni soubor do jineho swf souboru, ve kterem pouzijes tuto meodu), tak na externi texty (at uz v xml ci jen v txt souborech).

Pokud vim, je to jediny zpusob, jak se to da resit.

Nutno poznamenat, ze pokud je XML, ktere se nacita do flashe, generovano pomoci PHP, nezaznamenal jsem problem s chace a nebylo to nutne vubec resit.

embee:
„vzdy se to resi stejnym zpusobem - za url, kterou nacita flash pridas ?+random number -> generujes url“
Možná lepší než náhodné číslo je přidat aktuální čas (timestamp) nebo tak něco.

Joker
ja bych rekl, ze trefit se dvakrat do stejneho cisla o 4ech cifrach po sobe pri pouziti random algorytmu (flash takovy ma) je prakticky vyloucene... takze nevidim rozdil.

Ale urcite by to fungovalo taky :)

Reaguji na embee:
„trefit se dvakrat do stejneho cisla o 4ech cifrach po sobe pri pouziti random algorytmu (flash takovy ma) je prakticky vyloucene“
Při čtyřech cifrách to ani moc vyloučené není. Pokud čteš ten soubor opakovaně (třeba každých deset sekund), může se docela snadno stát, že se trefíš do některého z čísel, které už jsi vygeneroval dřív a sáhneš si do keše pro ještě starší verzi, než je ta naposledy stažená.

Doporučuji používat spíš těch 16 cifer, které se běžně ukazují při převodu floatu na řetězec.

Chamurappi
ja mel za to, ze se resi pouze rozdil od posledniho nacteni (-> zmena dokumentu), nikoli od veskerych nacteni.

embee:
„ja bych rekl, ze trefit se dvakrat do stejneho cisla o 4ech cifrach po sobe pri pouziti random algorytmu (flash takovy ma) je prakticky vyloucene“
Viz Chamurappi, problém je, že nestačí dostat jiné číslo než minule, musí to být jiné číslo než při všech minulých pokusech, které jsou ještě v cache.

Časové razítko by zas mělo nevýhodu, kdyby bylo potřeba odlišit pokusy následující po méně než sekundě.

To nicmene znamena, ze casem se nevyhnutelne musi kazda takto osetrena stranka dostat do faze, kdy uz nejsou zadna dalsi cisla dostupna ne?

U beznych stranek by to nebyl problem, ale co stranky, ktere maji tisice kliku za mesic?

„Časové razítko by zas mělo nevýhodu, kdyby bylo potřeba odlišit pokusy následující po méně než sekundě.“
Pokud by to vadilo, je možné k časovému razítku přidat dáhodné číslo.

embee:
„To nicmene znamena, ze casem se nevyhnutelne musi kazda takto osetrena stranka dostat do faze, kdy uz nejsou zadna dalsi cisla dostupna ne?“
Mno, teoreticky ano.
Třeba mnou navrhované časové razítko dosáhne na 64-bitovém systému své maximální hodnoty 4. prosince roku 292277026596, nicméně bych řekl, že za 292 miliard let nebudou existovat dnešní prohlížeče, dnešní počítače ani Sluneční soustava, takže je to vcelku jedno :-)

Joker
aby ses nedivil :D

Reaguji na embee:
„casem se nevyhnutelne musi kazda takto osetrena stranka dostat do faze, kdy uz nejsou zadna dalsi cisla dostupna ne?“
Pokud nic nepřeruší její běh, tak ano. Existuje víc druhů keší a ty, které se nepoužívají bezprostředně v rámci jedné návštěvy stránky (či flashe), už respektují kešovací HTTP hlavičky.


Reaguji na Jokera:
„nicméně bych řekl, že za 292 miliard let nebudou existovat dnešní prohlížeče, dnešní počítače ani Sluneční soustava“
Uvidíme. Zatím je panika okolo Y292G opravdu předčasná.