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 [email protected] http://www.py.cz/mailman/listinfo/python
