[python] kterak vhodne resit architekturu IMAP klienta

[Jan Matejka]

> > IMHO oddelovat UI od mailboxu frontou nemá smysl protože UI 
> potrebuje 
> > pro zobrazovaní okamzitou odpoved relevantnich dat nebo 
> odpoved "data 
> > nejsou k dispozici".
> 
> Potrebuju chovani "ok, mas tu data", "data budou za chvili" 
> nebo "chyba".
Ano.
> 
> > Naopak parser bych nechal bezet ve zvlastnim threadu.
> 
> Jake by to melo vyhody?

Tak jak jsem se na to dival je mailbox z pohhledu UI modul ktery je schopen
okamzite synchronne odpovidat na pozadavky UI. Pokud by UI melo komunikovat
s mailboxem pres frontu, tak by UI muselo, aby mohlo  fungovat, přebírat
funkci cache, kterou chceme mit v mailboxu. 
Uvazoval jsem ze zmeny ke kterym v mailboxu dojde by byly oznamovany ve
stejnem threadu jako bezi UI formou synchronnich zprav, ktere by UI
zachycovalo, tzn. fronta by nebyla nutna. 
Z pohledu parseru by mailbox slouzil jako databaze pro ukladani vysledku
nactenych dat, ukladat by je tam mohl přes frontu. Podobně pozadavky na
komunikaci s imap serverem by si parser odebiral z fronty ktera by byla
plnena mailboxem.

> 
> > Snazil
> > bych se o to, aby daval data v takove podobe, aby sly 
> rychle zaradit 
> > do datovych struktur mailboxu, aby aktualizacemi mailboxu nebylo 
> > blokovano UI.
> 
> Mno, mne se libi to, ze Parser fakt jenom parsuje. Kvuli 
> celkem komplikovane architekture IMAPu se dost brutalni 
> logice v Mailboxu nevyhnu.
> 

Pro seriozni diskusi by to asi chtelo rozdelit na vetsi mnozstvi funkcnich
bloku, s tim ze nektere bloku budou moci byt v řešení sloučeny. 
Jan Matejka