vineri, iulie 29, 2005

Organizarea finala

Aceasta este schema finala de lucru, in urma discutiilor pe care le-am avut cu fiecare:
  • Eu, Mihai si cu Mircea vom lucra la XMPPLib si la clasele de interfatare cu UI-ul.
  • Vlad si Alex Carp se vor ocupa de interfata in Avalon. Intrucat Alex Carp e plecat in momentul de fata si n-am reusit sa aflu nimic de la el, in cazul in care nu o sa vrea sa lucreze in echipa noastra, o sa-l ajut si eu pe Vlad la realizarea interfetei.
  • Ciprian si Stefan se vor ocupa singuri de Type Assistant, si mai vedem noi cum il integram in JabNet.
In ceea ce priveste XMPPLib, am inceput sa desenez diagrama UML a claselor publice care o vor forma. Mihai o va continua (ma astept sa dezvolte in special subclasele lui XmppStanza), si apoi o vom aduce la o forma cat de cat finala si implementabila. Din acel moment, eu, Mihai si cu Mircea ne vom imparti sarcinile de lucru, fiecare avand de lucrat la un anumit grup de clase. De remarcat faptul ca diagrama se refera numai la partea publica a librariei; orice alti membri privati sau protejati pot fi adaugati la nevoie, inclusiv creerea de noi clase private. Conteaza ca totul sa mearga in final :). Diagrama o gasiti pe site-ul pe care vi l-am trimis pe mail la fiecare.

Ar mai fi de facut un mic comentariu, legat de cum va fi folosita in final libraria: sincron sau asincron. Daca va fi implementata sincron, un apel la o metoda din clasa XmppClient va bloca firul curent de executie pana cand operatia cu pricina va fi gata. De exemplu, la operatia de log-in, metoda LogIn() va astepta pana cand ori serverul raspunde afirmativ sau negativ, ori timpul de asteptare al conexiunii expira.
Daca implementarea este asincrona, la apelarea metodei aceasta se va intoarce imediat la punctul de executie precedent, si instiintarea clientului asupra eventualelor evenimente se va face sub forma de event-uri.

Eu propun varianta asincrona, in care obiectul XmppClient va crea un fir de executie separat, in care va comunica intern cu serverul intr-un mod sincron, si folosind obiecte de comunicare inter-thread (mutex, event, monitor, etc.), va asigura un sistem de evenimente corespunzator cu obiectele care si-au inregistrat eventhandler-ele.