[python] kterak vhodne resit architekturu IMAP klienta

[Jan Matejka]

> Ok, ale co tahle situace:
> 
> Mam zobrazene maily v mailboxu ("slozce", ted nemluvim o 
> komponente/modulu). Kliknu si na paty mail. UI rekne Mailboxu 
> (velke M, takze komponente) "chci strukturu pateho mailu". 
> Jenomze chudak Mailbox to nema v cachi, a tak si musi povidat 
> s IMAP serverem. Posle proto UI zpravu "hele, sorry, zatim to 
> nemam". Tohle mi moc synchronni neprijde.

Proc? UI zavola metodu Mailbox.DejMiStrukturuMejlu a Mailbox v navratove
metode
odpovi "o tomto emailu nic nevim". UI tedy zobrazi presypaci hodiny a zavola
Mailbox.ZjistiInformaceOmejluAinformujMeProstrednicvimObjektuN. Mailbox si
to nekde poznamena a zapoveluje parser aby az bude vhodny okamzik informace
ze serveru vytahl.
Po case Parser ziska data, posle je Mailboxu, mailbox zavola prislusnou
metodu podstrceneho UI objektu N,  UI zavola Mailbox.DejMiStrukturuMejlu,
tentokrat vsak data dostane a zobrazi je.

> 
> Cili shrnuti - synchronni komunikace nefunguje, protoze 
> Mailbox *nezarucuje*, ze ma porad k dispozici vsechna data. 
> Prefetch dat ze serveru musi byt volitelny a i pokud se 
> povoli, tak je potreba nejaka logika, protoze je kravina 
> bezmyslenkovite stahovat cely attachment, kdyz chce user 
> videt jenom plaintextovou cast mailu a pak ho smazat, napriklad.
> 

V tomto zcela suhlasim.

> Co ma teda delat UI? Muze zobrazit "cekej" misto obsahu 
> mailu, ok. Jak ale pozna, ze uz ty data dorazily Mailboxu? Callback?
> 
> Mozna ale mas pravdu. Pokud te dobre chapu, tak ty navrhujes 
> neco jako "pokud data nejsou hned, Mailbox postupem casu 
> zavola callback". Je to tak? Tim padem Mailbox rekne "zatim 
> ten mail nemam", ale az dorazi, pusti callback, ktery rekne 
> UI "struktura mailu s UID 12345 je XYZ".
> (UID 12345 je nutne kvuli tomu, ze si user zatim moh 
> odscrollovat na jinej mail. Mailbox ale stejne cte data. 

Ano myslel jsem to tak viz vyse.

> Mozna komplikace - je tohle nejlepsi postup? Co delat, kdyz 
> user klika na jeden mail za druhym?
> Takhle by Mailbox dostal request na vsechny, coz je mozna trosku
> zbytecny...)
> 

V tom pripade by bylo treba nejak zajistit moznost ruseni pozadavku. 
Tzn. pozadavky ihned neposilat z Mailboxu do fronty Parseru.  Frontovat tedy
pozadavky jeste v mailboxu aby nad nimi mel kontrolu.

> Ty fronty, co jsem navrhoval ja, by IMHO nemusely znamenat, 
> ze UI cachuje. Naopak, pokud UI dostane zpravu, na kterou 
> nemusi reagovat (protoze IMAP definuje treba situace, kdy je 
> nutne upozornit usera etc) a ktera se mu podle nej nehodi, 
> muze ji smele ignorovat, protoze si o ni muze zazadat i jinak.
> 

Jde o to na jake urovni cachovani uvazujeme, pokud by UI nemelo drzet pokud
mozno zadna data, tak je treba aby byla z mista kde jsou ulozena dotupna
rychle a to by v pripade front nebyla, takze by to UI muselo resit
cachovanim.

> Takze jak tak na to koukam, ono ty fronty asi ani neprinaseji 
> zadnou vyhodu, mozna tak takove opticke oddeleni dvou slupek. 
> Spis je ale horsi, ze muzou vnest nejakou tu latenci...
> 
> Diky za postrehy, nekdy se nad tim budu muset poradne zamyslet, -jkt
> 

> cd /local/pub && more beer > /dev/mouth
:)