* Chi: Claudio Zaffiro Fabio Sciancalepore Alvise Rossano (amministratore) a.gulli@atwork.it * Calendario: ** primo incontro SCHEDULED: <2011-06-08 Wed> ** secondo incontro Claudio esporra' il progetto entrando nei dettagli SCHEDULED: <2011-06-15 Wed> * Descrizione: Progettazione social network, mi hanno cercato per la parte PostgreSQL e MongoDb ma il progetto pare in fase embrionale ed è necessario analizzarlo per capire come raggiungere gli obiettivi posti. * Come spiegare l'utente scrive sul browser un indirizzo internet, questo interroga il dns per risolvere il nome in IP, crea una connessione all'IP ottenuto sulla porta propria del protocollo richiesto dall'URL. Il server riceve la connessione su quella porta e la dirige al demone connesso ad essa, tipicamente un web server. Il browser quindi invia su questa connesione una richiesta (http request). Se la richiesta e' relativa ad una risorsa statica il webserver può gestirla autonomamente e rispondere al browser. poi scendere nei dettagli: ** pagina web: tante connessioni per ottenere tutto quanto server per la visualizzazione *** il browser non effettua tutte le chiamate in parallelo, limita il numero di richieste simultanee per singolo hostname *** il protocollo HTTP 1.1 mantiene aperta la connessione tra le varie richieste, la versione 1.0 no. ** javascript (un file vs molti file) ** icone (un file vs molti file) ** domain name resolver (singolo vs multi IP) ** reverse proxy (ESI) ** CDN ** load balancer ** come una richiesta viene eseguita dalla macchina, passaggio dei dati, context switch, uso della ram, uso della shared memory, tempi di esecuzione, tempi di seek dei dati ** comunicazione tra front-end e back-end (SOAP, XML-RPC, JSON-RPC, Coda messaggi) ** le cache (browser, proxy, reverse proxy, web server, memcache, front-end app, back-end app, db, fs) ** la composizione della pagina (interamente da una web-app o da piu' di una) ** chiamate ajax ** comunicazioni webserver e applicazione (mod_*, cgi, fastcgi, scgi, altro) ** autenticazioni (SSO) ** autorizzazioni ** SSI, template, moduli e pattern ** filesystems i tempi di accesso al disco, i tempi di seek, come avere un fs distribuito e come condividerlo ZFS HammerFS AFS (per cloud storage) ** altri temi *** localizzazione *** ORM *** SEO * Autorizzazioni e acquisto features Gli enti e gli utenti possono acquistare delle feature o avere abilitate per alcuni periodi di prova alcune di esse. Gli enti sono dei gruppi di utenti. Le feature sono dei gruppi di azioni che implementano certe funzionalità. Le azioni sono le parti atomiche url mapped dei servizi che appartengono alle feature. Una azione puo' appartenere ad zero, una o piu' feature. Una azione che non appartiene ad alcuna feature rappresenta o parte di una feature in sviluppo o un'azione pubblica. Le feature possono essere erogate per un certo tempo o a consumo (ad esempio N SMS da inviare). I contratti hanno delle tipologie, a ciascuna tipologia corrisponde un certo testo con le condizioni contrattuali. I contratti colletivi sono quelli stipulati con il partner che rappresentano il contratto base per l'utente che appartiene all'ente partner, tuttavia ogni utente puo' avere una diversificazione con maggiori servizi. L'amministratore dell'ente partner puo' stabilire la propria gerarchia di ruoli per i propri utenti, i ruoli sono disposti su un solo asse: * ogni ruolo ha un valore sociale univoco per il partner * ogni ruolo ha associati i servizi che il partner puo' aggiungere o togliere ai propri ruoli. L'obiettivo di questo design e' quello di consentire una rapida identificazione delle autorizzazioni che l'utente gode sulle singole azioni in modo da semplificare e minimizzare l'accesso al db. Mentre rimane un problema la creazione delle tipologie di contratto e l'associazione a ciascuna tipologia dei default che essa deve contenere. Per questo aspetto sarà opportuno pensare ad una interfaccia utente dedicata per i commerciali o per chi ne fara' le veci sul sistema. Ogni servizio avra' un metodo virtuale che ne calcolerà il costo e lo attribuirà all'utente. Per quelli a consumo va definito se ogni servizio ha un contatore che raggiunto lo zero lo disabilitera' o se ogni servizio ha un "costo" che eroderà un credito complessivo che viene assegnato all'utente. Ad esempio: all'utente viene attribuito un credito di 1000 (che l'utente ha pagato per acquisirlo, o che gli e' stato attribuito per permettergli di godere di una serie di prove). E' chiaro che in questo modo l'utente potrebbe usufruire del credito per consumare altri servizi tra quelli che ha abilitati e non necessariamente quello che si vorebbe dargli in prova. Pero' questo approccio semplifica l'implementazione in quanto permetterebbe di evitare di gestire X contatori per X servizi per ogni cliente. Altro problema: se e' l'ente che acquista 1000 crediti per i suoi servizi, ogni utente dell'ente andra' a consumare il credito condiviso. Un utente che appartenga ad un ente ma che acquista un servizio aggiuntivo, puo' sottoscrivere anche solo per se' stesso? O diversamente: un commerciale potrebbe attribuire in prova un certo servizio ad un ruolo specifico di un ente? /* * i numeri servono solo a ordinare i ruoli tra loro e stabilire una gerarchia * * sys: e' la atWork che quindi ha N utenti con diversi ruoli ciascuno: * tester 1 * utenti del backend 100 * commerciali 2000 * sistemisti 100000 * * end user: sono gli utenti non collegati ad un ente dotato di contratto partner * welcomer 5 * newbie 10 * photographer 100 * cameramen 200 * seeker 300 * deluxe 400 * premium 1000 * * Ogni ruolo ha un livello sociale che lo rende ordinabile rispetto agli altri ruoli * della stessa tipologia. */ create type PartnerType as enum ('sys','end user','media','police','organization','social','ecology'); create table AgreementTypes ( id serial primary key, next integer, title text, type PartnerType not null, url text not null, created timestamp default now() ); alter table AgreementTypes add foreign key(next) references AgreementTypes on update cascade; create table Agreements ( id uuid primary key, ); create type erogation_modes as enum ('by credit', 'expire date'); create table Services ( id serial primary key, name text not null, description text, erogation_mode erogation_modes not null, ); Per scoprire di quali servizi gode un utente si uniscono i suoi con quelli dell'ente di appartenenza: select servizi from servizi_utenti where id=$1 union select servizi from servizi_partner where id_partner=(select id_ente from utenti where id=$1); // in $1 l'id dell'utente select * from feature_servizio as fs,azioni_feature as af where sf.id_servizio=? and sf.id_feature=af.id_features;