Re: [python] kterak vhodne resit architekturu IMAP klienta
Pokracuju v metode radsi si to prectu pozdejc, protoze nad tim musim myslet, a tudiz na mail uspesne zapominam. Inu sorry za pozdni reakci :). Jan Matejka wrote: 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. Aha, ok. Jak to tak vidim, tak se bez nejakeho bufferu na pozadavky stejne neobejdu, viz obrat Mailbox si to nekde poznamena. Je otazka, na jake urovni je to lepsi resit... 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. Mno, otazka je, jak rychlou odpoved muze Mailbox aspon trosku garantovat. Pokud bych se drzel sve puvodni koncepce, nemel by byt problem - Mailbox se v nejake smycce diva do dvou front, jestli nahodou neprisel nejaky pozadavek od UI nebo data od serveru, pokud ano, tak nejak reaguje. Podstatny je, ze jakykoli blokovani na I/O urovni (prerusene spojeni se serverem,...) Mailbox neovlivni, protoze bezi v jinym threadu nez Parser... Zkratka a dobre, dekuju za podmety, zamyslim se nad tim, mozna si o tom nad pivem popovidam a pak uvidim :). Hezky den, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] kterak vhodne resit architekturu IMAP klienta
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 ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] kterak vhodne resit architekturu IMAP klienta
Jan Matejka wrote: Tak jak jsem se na to dival je mailbox z pohhledu UI modul ktery je schopen okamzite synchronne odpovidat na pozadavky UI. 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. 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. 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. 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...) 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. 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 -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] kterak vhodne resit architekturu IMAP klienta
Dobrého dne, jsa asi ovlivněn modelem dokument-view bych to videl spis tak, ze mailbox bude s UI komunikovat primo prostrednicvim metod mailboxu volanych z UI a callbacku kterym bude mailbox oznamovat UI, ze ze se v mailboxu něco zmenilo. IMHO oddelovat UI od mailboxu frontou nemá smysl protože UI potrebuje pro zobrazovaní okamzitou odpoved relevantnich dat nebo odpoved data nejsou k dispozici. Naopak parser bych nechal bezet ve zvlastnim threadu. 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. zdravic Jan Matejka Ted resim problem, jak maji tyhle tri slupky spolu komunikovat. Jako uplne prvni vec me napadlo to, ze kazda z nich pobezi ve vlastnim threadu a vsechno si budou rikat pres Queue.Queue (vzdy dvojice mezi jednotlivymi slupkami). Po zapnuti mozku mi ale doslo, ze se Parser a Mailbox daji krasne sloucit - proste v ramci jednoho cyklu thread zkontroluje, jestli po nem neco nechce UI nebo jestli neco neprislo od IAMP serveru. Zbyva teda vyresit, co s komunikaci mezi Mailboxem a UI. Premyslim o dvojici front, pro kazdy smer jednu. Ve smeru UI - Mailbox proudi prikazy typu smaz zpravu XYZ, ukaz mi razeni do threadu ci dej mi hlavicky zpravy cislo 12, opacne data jako treti megabajt sedme prilohy zpravy cislo 13 je \x00... ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] kterak vhodne resit architekturu IMAP klienta
Jan Matejka wrote: Dobrého dne, jsa asi ovlivněn modelem dokument-view bych to videl spis tak, ze mailbox bude s UI komunikovat primo prostrednicvim metod mailboxu volanych z UI a callbacku kterym bude mailbox oznamovat UI, ze ze se v mailboxu něco zmenilo. Ahoj, zkusim nad tim zapremyslet. Model-View-Controller uz jsem taky cet :) 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. Naopak parser bych nechal bezet ve zvlastnim threadu. Jake by to melo vyhody? 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. Diky za reakci, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
[python] kterak vhodne resit architekturu IMAP klienta
Ahoj, pracuju na Yet Another IMAP klientovi [1]. Cilem ma byt neco, co mi bude vyhovovat, bude se ridit RFC 3501 a dalsimi relevantnimi, bude s IMAPem pracovat efektivne a spravne :). Dalsim pozadavkem je vice ruznych UI -- neco v Qt, neco v necem jako ncurses -- a taky rozumne interaktivni prace (download velke prilohy nesmi omezit plynulost dalsi prace a uz vubec ne reakce od UI). Zatim se mi celkem zamlouva desing pracovne nazyvany tri slupky: a) IMAP parser -- vec, co prevadi stringy od serveru na proud objektu (kazdy z nich reprezentuje urcitou odpoved od serveru) a prikazy od neceho jinciho na stringy pro server. +/- hotovo. b) Nabusena vec pracovne nazyvana IMAPMailbox - cosi starajici se o udrzovani +/- presne predstavy o mailech v mailboxu, cachovani,... c) UI, naprosto stupidni vec, ktera bude jenom zobrazovat. Neni problem, aby se IMAPMailboxu ptala na stejnou vec tricetkrat po sobe, protoze to onen bude mit nacachovane. Ted resim problem, jak maji tyhle tri slupky spolu komunikovat. Jako uplne prvni vec me napadlo to, ze kazda z nich pobezi ve vlastnim threadu a vsechno si budou rikat pres Queue.Queue (vzdy dvojice mezi jednotlivymi slupkami). Po zapnuti mozku mi ale doslo, ze se Parser a Mailbox daji krasne sloucit - proste v ramci jednoho cyklu thread zkontroluje, jestli po nem neco nechce UI nebo jestli neco neprislo od IAMP serveru. Zbyva teda vyresit, co s komunikaci mezi Mailboxem a UI. Premyslim o dvojici front, pro kazdy smer jednu. Ve smeru UI - Mailbox proudi prikazy typu smaz zpravu XYZ, ukaz mi razeni do threadu ci dej mi hlavicky zpravy cislo 12, opacne data jako treti megabajt sedme prilohy zpravy cislo 13 je \x00... Co vy na to? Je nejake lepsi reseni? [1] http://svn.flaska.net/viewcvs/trojita/ -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
