h3. Cum alegem tehnologie
De multe ori s-a discutat ca infoarena sa folosesca o anume librarie avansata sau framework. Folosirea unei librarii externe este o decizie majora care trebuie analizata cu grija. O dependinta externa trebuie sa satisfaca urmatoarele conditii:

* Sa fie simplu de inclus. Sa existe macar pachete debian si fedora; sau sa poata fi copiata direct in svn. *Nu* se accepta installere din afara distributiilor de linux.
* Sa ne ajute cu ceva major care ar fi foarte greu sa facem de la 0.
* Sa fie cunoscuta si dezvoltata activ. Altfel probabil ca respectiva librarie nu e foarte buna.

Vrem sa suportam minim MySQL pentru productie si SqlLite pentru development. Ar fi foarte util sa putem rula site-ul in modul de development fara o procedura complexa de setup.
Avem nevoie de o schema a bazei de date inainte de a ne apuca serios de lucru. Probabil ca o sa scriem direct modelul sql alchemy. Cateva idei:

* Atasamentele intra in baza de date ca blob-uri. Facem cache pe disk in serveru' de web; dar doar cache.
* Refacem ia_textblock, face doar stocare versionata de blob-uri. De investigat merge cu ia_file.
* Id-ul numerice peste tot.

h3. Wiki
La baza site-ului vom avea o componenta de versionare de fisiere. Aceasta componenta nu stie absolut nimic de useri, probleme, securitate sau tag-uri. Orice semnificatie a fisierelor este data doar de mai sus. De la aceasta componenta ne dorim urmatoarele:

 * Fetch rapid, cu cache transparent pe disc. Nu servim fisiere direct baza de date.
 * Istorie completa a modificarilor
 * Delete reversibil, care sa apara in istorie

 * Posibilitatea de a distruge complet o revizie
Nu avem nevoie de:

 * Directoare. Ne trebuie doar fisiere.
 * Meta-date. Versionam doar blob-uri; eventual cu cateva coloane strongly-typed (mime type?)
 * Notiuni de securitate.

h3. Securitate
Securitatea se va face in codul de BL si va fi implementata distinct pentru fiecare tip de entitate. Fiecare utilizator va avem anumite permisiuni global iar pentru unele entitati vom putea adauga drepturi per-utilizator. Incercam sa facem securitatea cat mai simplu; in cod. Incercam sa evitam securitate declarativa dar prea complexa, cum e cea din windows. Nu vom suporta:

* Id-uri globale de obiecte securizabile.
* Grupuri de obiecte.
* Logica de allow/deny.

* Grupuri de utilizatori.
Fiecare utilizator va avea anumite drepturi globale. Aceste drepturi pot fi editate doar de administratori, folosind checkbox-uri sau dropdown-uri pe pagina de cont. Aceasta pagina trebuie sa fie accesibila din pagina de profil. Drepturile globale vor fi hard-codate la un moment dat, dar le putem schimba din cod.

* Daca utilizatorul este admin
* Daca poate propune probleme
* Daca poate posta pe blog

* Daca este moderator pe forum (challenge!)
Pentru probleme o sa avem o lista in care pot fi adaugati useri cu drepturi.

* Propunator: Aproximativ orice
* Reviewer: Modificari in enunt, download de teste.
* Altceva?
Pentru runde putem incepe prin a permite accesul doar administratorilor, dar ulterior putem adauga o lista de useri cu drepturi:

* Responsabil: poate sa modifice orice.
* Tester: poate submita la probleme in afara concursului.
* Invitat: pentru concursuri private sau finale live.

h3. Barebones read-only site
Ca prim pas trebuie sa facem intai partile de content. Daca avem tot continutul importat putem sa facem teste foarte realiste si sa vedem cat de viabile sunt ideile noastre. Nu incepem cu pagina de inregistrare utilizator. Ne trebuie:

* Schema sql alchemy pentru baza de date.
* Script import baza de date
* Servire textile cu macro-uri