Rychly mail client alebo linux nie je pomaly

[Matus UHLAR - fantomas]

Peter Surda <shurdeek na routehat.org> wrote:
> On Sun, 22 May 2005 11:03:57 +0000 (UTC) Matus UHLAR - fantomas
> <uhlar na fantomas.sk> wrote:
> 
>>Peter Surda <shurdeek na routehat.org> wrote:
>>> Vsetky skusane webmaily boli take pomale preto, ze pri kazdom kliku
>>> komplet loadovali cely folder, sortovali ho atd. Na toto dovod nie je,
>>> mozes si to cachovat a cez imap transferovat len msgid (tak to robia
>>> "poriadne" clienty).

>>co je z principu na webmailoch dost tazko implementovatelne.

> Ocividne to neplati, lebo mne sa to implementovat podarilo. Sice bez
> imapu, ale ako som povedal nevidim v tom principialny problem, len by sa
> mi to tazsie programovalo (perl vs. C). A este mam rezervy.

jednak som napisal "dost tazko" jednak sa obavam ze su tu aj veci, ktore z
principu implementovat nemozes. Teda istym sposobom ano, vid nizsie.

>>kedze kazdy http request znamena nove vyvolanie skriptu.

> Nie je pravda. Ja pouzivam FastCGI a tam sa to nedeje (napriek tomu este
> stale data session necachujem, takze potencialy na zrychlenie nie su
> vycerpane).

ale napriklad, ked k webmailu pristupuju dvaja pouzivatelia naraz, musia sa
spustit minimalne dva fastcgi skripty. A cim zarucis, ze tu istu session das
vybavit vzdy tomu istemu FastCGI skriptu, ktory bude mat vsetko nakesovane?

Jedine tym ze kazda session bude mat vlastny FastCGI skript, ale toto musis
osetrit na urovni httpd.

mas to vyriesene takto?

> Pomoze mi ale, ze sa nemusi pri kazdom kliku parsovat perlovy skript,
> robit spojenie na databazu a dalsie veci, ktore overene maju
> nezanedbatelny vplyv na vykon.

spojenia na databazu dokaze cacheovat aj PHP cez persistent connections.

>>Toz, bezstavovost HTTP ma svoju cenu

> Ani "bezstavovost" nie je nevyhnutnou podmienkou webmailu.

Bezstavovost nie je podmienkou ale negativnou strankou pouzitia HTTP. 

> Co ti brani prepojit session id a nejaky adresar s cache? Staci ked si
> zoberes perlovsky modul CGI resp. CGI::Fast, tie implementuju stavovost.
> Ako som vsak povedal, ja to este stale nerobim a napriek tomu som to
> enormne zrychlil.

nepovbedal som ze mi nieco brani to takto urobit. Tvrdim, ze nemozes
predpokladat, ze klient s webserverom budu komunikovat vzdy po tom istom
HTTP spojeni, a neda sa to ani urobit v ramci jedneho HTTP requestu.

stavovost pri HTTP neexistuje, ty si ju musis nejako nahradit, a to je jeden
z dovodov, preco je webmail z principu menej efektivny ako napriklad IMAP.

>>a pouzitie HTTP na webmaily nie je bohvieaky napad.

> Preco? Je to univerzalne pouzitelne a ako sa mi podarilo demonstrovat, da
> sa to naprogramovat aj efektivne.

pre dovody ktore som uviedol vyssie. pretoze o stavovost sa musis postarat
sam a pouzit pre nu mechanizmy, ktore v stavovych protokoloch ako IMAP nie
su potrebne, respektive su implementovane nativne.

>>je tu niekolko principialnych dovodov aby to bolo dost pomalsie ako praca s
>>obycajnym mail klientom.

> Nie je. Kvoli zavislosti na HTTP(S) to moze byt trocha pomalsie, nie vsak
> "dost". Ti, co sa ohanaju "principialnymi dovodmi" mozno len nevedia
> programovat
> :-).

dovody som vymenoval vyssie. Sice sa to da naprogramovat viac alebo menej
efektivne ale vzdy tu bude treba riesit veci sposobene.

A ti, co tvrdia ze to po webmaili je rovnako efektivne ako imapom zrejme
vobec nepochopili co je HTTP a IMAP. A zrejme maju prehnanu mienku o svojom
programatorskom umeni.

-- 
Matus UHLAR - fantomas, uhlar na fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901