Proc IDOS pouziva Cookies

[Martin Mares]

Zdravim,

[Ac vim, ze pokracovanim v tomto threadu jeste vice zneprijemnuji zivot tem,
jez vubec nezajima, pokusim se alespon na vsechno reagovat najednou, takze
prosim omluvte, ze micham prispevky jednotlivych autoru.]

> To je tak akorat na FlameWar typu "Ktery OS je lepsi".
> Duvodu je vice, vcetne historickych. ASP poskytuje z hlediska vyvojare mnoho
> uzitecnych vlastnosti pro podobne aplikace jako stvorenych.

   Ano, jako stvorenych, nicmene (coz je primarni tema teto debaty) implementovanych
IMNSHO dosti neprimerenym zpusobem.

[...]

> Abych pravdu rekl, ja ten format take neznam.
> Ale zkuste pozadavek uplatnit napr. u Ing. Rakusana,
> rakusan at datis.cdrail.cz (sedi o cca 120 km dale).
> Je vsak temer jiste, ze Vam nevyhovi.
> CD garantuje platnost dat a ta se pomerne casto meni.
> Naposledy ted ze So na Ne v noci.
> Jiny provozovatel by tuto garanci poskytnout nemohl
> a nabizel by neplatne informace.

   Jestlize CD zverejni sva data na verejnem FTP-serveru a budou je tam
aktualizovat, ostatni mohou tato data trivialne mirrorovat a tak se dozvidat
o vsech zmenach.

   Co se garance platnosti dat tyce, mam jeste v zive pameti, kdyz jsem
na zacatku lonskeho cervence vyhledaval IDOSem spojeni z Prahy do Kralovic
u Rakovnika a dostal jsem odpoved, o ktere jsem o par hodin pozdeji zjistil,
ze ani jeden z vlaku, ze kterych se spojeni skladalo, neexistoval. Toto berte
nikoliv jako invektivu proti IDOSu, nybrz jako dukaz toho, ze zadne garance,
at jiz poskytovane kymkoliv, nemohou byt 100%ni.

> Sem s namety.
> Nikdo nevymysli nic idealne, uvitam namety na
> zlepseni IDOSu (vim, ze mame nektere rozdiskutovane).

   Mym zakladnim nametem bylo zverejneni dat.

[...]

> Opravdu to nechapete.
> Nejde o Cookie. To je jen nastroj pro vytvoreni Session
> a Session vytvari stovove prostredi. Prectete si, proism,
> dokumentaci k ASP.

   Nerad bych hodnotil, co znaji ostatni ucastnici teto konference, ale rekl bych,
ze toto jest zde vseobecne znamym faktem. Osobne bych spise doporucil studium
dokumentace od HTTP, zejmena pak RFC 2068 a RFC 2109, ktera podle meho nazoru
vrhaji dosti svetla na to, nakolik je diskutovane pecivo vhodne pouzivat.

> On ale nepada (protoze pouziva Cookies a Sessions :-) ).
> Pouze nekteri uzivatele maji problem, ze si vypnou Cookies,
> a pak si mysli, ze server pada.

   Muj ciste subjektivni nazor (mozna zkresleny pouzitou `metodou mereni')
jest ze za posledni dva mesice byl IDOS dole vicekrat nez za predchozi rok
dohromady.

> > Podle meho nazoru jste stale neuvedl
> > duvod, proc by se tohle muselo delat pres cookies.
>
> No prece proto, ze v ASP je Session implementovana pomoci
> Cookies. Co je na tom, proboha, tak nepochopitelneho?

   Otazku lze tedy preformulovat na "... proc by se tohle muselo delat
pres ASP sessions?".

[...]

> Kdyz Vam dam zdrojaky, tak uz toho moc programovat nemusite ne?

   Pokud to budou zdrojaky knihovny na vyhledavani spojeni, pak je jeste
nutne napsat cely WWW interface...

> Ono je jedna vec mit silna slova a druha vec je pak podeprit
> nejakym cinem.

   Pokud mi kdokoliv da budto zminovane zdrojaky nebo popis formatu dat, mile
rad je cinem podepru.

[...]

> Nevim, zda jste cetl cely thread.
> Vyhledavaci algoritmus je realizovan .DLL
> knihovnou.
[... smik, smik, smik, tisici a prvy popis knihovny bych jiz nerad citoval ...]

   Ano, ja pouze mluvil o tom, ze tento zpusob interfacu vyhledavaciho serveru
je daleko mene vhodny pro prakticke pouziti nez cache zavisla na _kontextu_,
ktera sdili uchovavane informace mezi _vsemi_ uzivateli, coz ma principialne
vyssi efektivitu.

> Ano, presne toto vyse popsany mechanizmus vlastne dela.
> Ta cache jsou vlastne datove struktury v pameti obsahujici
> predvyhledana data o spojeni.

   Ano, ale nevidim duvod, proc by tyto struktury nemohly byt asociovany
se samotnym _textem_ pozadavku misto se session, ke ktere patri.

> Navrhuji tento namet prednest napr. v diskusnim
> foru CD, protoze jej ctou zodpovedni lide z CD,
> kteri mohou o podobnych vecech rozhodovat.

   Jiz se na tom pracuje...

[...]

> CD vydavaji zmeny jizdniho radu. Ty zmeny jsou pravidelne i nepravidelne
> (viz povodne) vydavane. Nekdo, samozrejme CD musi zajistit aktualnost
> databaze. A ted mi prosim reknete, jak by to zajistily v pripade, ze tady
> bude nejakych 5-10 serveru poskytujicich stejne sluzby na nezavisle
> (organizacni) platforme.

   Viz mirroring zminovany vyse.

> Ja davam prednost tomu, aby tady byl jeden server.

   Uvedomte si, ze pokud tu bude vice (slusne synchronizovanych!) serveru, bude
to daleko spolehlivejsi a lide, kteri budou potrebovat _rychle_ vyhledat nejake
spojeni si nebudou tak rvat vlasy, kdyz zrovna onen unikatni server nebude
pro ne pouzitelny (at jiz proto, ze zrovna spadl ci proto, ze provider,
na nejz jsou drazni servery pripojeny ma speficke nazory na peering a linka
do sveta mu zrovna spadla [nenarazim na konkretni situace]).

				Have a nice fortnight
--
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"In accord to UNIX philosophy, PERL gives you enough rope to hang yourself." -- Larry Wall