Eventi/ ASPettando Inter.NET

di M. Corazzi. 'Abbiamo più futuro che passato'. Con questa considerazione il W3C da un colpo di spugna a tutto quanto è stato fatto finora. Alla Future Web Conference abbiamo scoperto come dovremo cambiare il nostro modo di creare il Web
di M. Corazzi. 'Abbiamo più futuro che passato'. Con questa considerazione il W3C da un colpo di spugna a tutto quanto è stato fatto finora. Alla Future Web Conference abbiamo scoperto come dovremo cambiare il nostro modo di creare il Web


Se il governo del nostro paese ha paura dell’informazione che circola nella rete al punto da approvare una legge che permetta alla lobby dei giornalisti di controllarla, significa che il nostro lavoro ha un grande potere.
Ci sono due categorie di persone: quelli per cui avere un grande numero di ascoltatori rappresenta una specie di droga, un trip di onnipotenza, e quelli che invece si sentono investiti da una grande responsabilità e soppesano ogni parola consci delle conseguenze che questa potrebbe avere. Il rischio di finire nella prima categoria è sempre in agguato, ma tutti quelli che conosco in questo ambiente stanno facendo un grande sforzo per rimanere invece nella seconda.
Ed è questo il motivo per cui ho riscritto completamente l’introduzione di questo articolo.

La Future Web Conference che si è tenuta Giovedì 5 Aprile a L’Aquila, capoluogo della regione Abruzzo, è stata un’iniziativa corale di grande effetto e con un ottimo livello di contenuti. Persino ai coristi più esperti può accadere, tuttavia, di produrre qualche nota stonata, anche se ad accorgersene è soltanto il pubblico più esigente ed esperto, che magari vive anche il “dietro le quinte” di una manifestazione.
Però il critico che prenda seriamente e onestamente il suo compito sa bene che le piccole stecche si possono perdonare ai debuttanti, e che una recensione obiettiva può aiutare a crescere e migliorare, mentre una stroncatura rimarrebbe sterile, solo un piccolo esercizio di sadismo.

L'ingresso al forte spagnolo, risalente al XVI secolo. La maestosa struttura ospita un museo, un auditorium e una sala conferenze dove si è tenuta la Future Web Conference, in un singolare incontro tra storia e futuro.

Una conferenza non è soltanto quello che viene detto sul palco dagli speaker. L’accoglienza, le strutture, le infrastrutture, i dettagli, i servizi aggiuntivi: un complesso e delicato mosaico in equilibrio instabile, e ogni pezzo è stato interpretato dalla relativa voce del coro con grande convinzione. Un chiaro sintomo che l’interesse per la rete sta crescendo anche nel nostro paese, grazie all’impegno e al fervore degli appassionati.
Nella presentazione dell’evento avevo sottolineato quella che secondo me era la grande novità di questa conferenza: lo streaming audio video in diretta dal sito live.aspitalia.com .

Purtroppo il supporto tecnico (e sto parlando di una banale T1 telefonica ISDN…) è venuto a mancare. Una leggerezza dell’organizzazione, un effetto collaterale dovuto all’enorme sforzo profuso da Daniele, Gianni e Mauro nel dirigere il resto dei cantori. La To-Do List di un progetto di questa portata è lunga, e comprende la gestione degli spazi, le luci, l’audio, le proiezioni, l’allestimento dei PC per le demo, i coffee break e il buffet (momenti fondamentali anche per lo scambio di idee). L’entusiasmo degli aquilani ha, d’altro canto, dato vita a qualcosa di realmente innovativo, un segnale di risveglio dell’Italia centrale che finora ha lasciato che fosse il nord a sostenere il carico dell’informatizzazione nel nostro paese.

Quindi non ci sentiamo di insistere su questo fatto se non per lodare l’efficienza di un improvvisatissimo team di tecnici costituito da Daniele Bochiccio e Stefano Scardovi di ASPItalia e da Riccardo Riccardi e Fabiano Andreotta di JSdir . In rocambolesche scene alla McGyver (collegamenti realizzati con nastro adesivo e temperino, scambi di cavetti al volo, download di driver dal portatile tramite cellulare o in albergo…) l’emergenza è stata affrontata e risolta per garantire comunque il servizio. In extremis, certo, con qualità delle immagini non di certo eccellente, su PSTN anziché su ISDN, ma comunque un primo, importantissimo passo. Il fatto che oltre 2400 utenti si siano collegati per assistere alla conferenza dimostra che la sete nel settore è grande, e che tutti dovremo lavorare moltissimo per placarla.

I cavalieri che fecero l'impresa: da sinistra Stefano Scardovi e Daniele Bochicchio di ASPItalia e Fabiano Andreotta e Riccardo Riccardi di JSDir che hanno lavorato freneticamente fino all'ultimo istante per lo streaming di FWC.

Non ci resta che sperare che in occasioni future gli sponsor e le istituzioni vengano investiti di maggiore responsabilità e che si assumano il compito di curare anche questi aspetti. Occorre veramente la collaborazione di tutti.

Chi mi ha colpito molto sono stati Roberto Brunetti e Paolo Pialorsi, i due speaker.
David Papini di Mondadori Informatica Education non stava facendo solo pubblicità quando ha affermato che i loro docenti sono scelti con cura per essere motivati e competenti. I due giovani esperti si sono alternati tra slide, demo e lunghi e serrati discorsi con grande maestria, derivante certo da naturali doti di comunicatori, da simpatia e affiatamento innati. Ma ho ravvisato chiari indizi di una notevole preparazione da parte di entrambi, frutto di lunghe ore trascorse a studiare e documentarsi, e a provare parole e passaggi. Inevitabile quello che si potrebbe definire “acceleration trauma”. La quantità e l’eterogeneità delle informazioni prodotte per unità di tempo ha shockato più di uno spettatore, ma l’avvertimento era chiaro: il target della conferenza era alto.


L’eXtensible Mark-up Language (XML) non è una grossa novità; è nato nel 1998 come “recommendation” del W3C, il consorzio per gli standard di Internet, quasi tre anni fa: più di un milione di beats , nell’unità di misura che la Swatch cerca di imporre a Internet e al mondo. Ma in pratica ancora pochi ne parlano, e meno ancora lo conoscono e lo usano.

Cosa effettivamente questo meta linguaggio sia è quanto di più banale: semplicemente una diversa sintassi per descrivere oggetti e relativi attributi, con qualunque grado di strutturazione. XML somiglia molto a HTML, anzi si potrebbe dire che se il secondo avesse regole sintattiche più rigide potrebbe benissimo essere una subclass del primo (che in realtà è stata ideata e si chiama XHTML).
Molta rilevanza, come in tutte le grammatiche formali, viene data ai concetti di documenti validi e ben formati. E questo è molto bello da un punto di vista teorico.

La postazione di ASPItalia. Tra gli oltre duecento partecipanti c'erano rappresentanti delle maggiori TLC italiane; nella foto il secondo da destra è il Dott. Marco Xodo di Albacom che è intervenuto con il suo collega Stefano Miccichè.

Però a noi interessa capire la portata dell’impatto di questo linguaggio sul mondo del web in qualità di giornalisti (senza offesa), e avere un quadro della sua potenzialità come sviluppatori.
La semplicità e chiarezza di XML lo rendono il candidato ideale a standard per la rappresentazione dei dati.
Un piccolo esempio permetterà di visualizzare il concetto.


 
<oggetto>
	<componente1>
		<attributo1> valore1 </attributo1>
		<attributo2> valore 2 </attributo2>
	</componente1>
</oggetto>
 

oppure


 
<oggetto>
	<componente1 attributo1="valore1" attributo2="valore2">
</oggetto>
 

Le specifiche sintattiche di un linguaggio di questo genere sono raccolte in una Document Type Definition (DTD, da non confondere con DDT) simile a quello di HTML. In alternativa si può ricorrere a XMLSchema, proposto da Microsoft al W3C, che descrive proprio in XML (ai matematici e ai programmatori piace tanto la ricorsione) le regole di validazione di un documento, supporta la tipizzazione ed è flessibile per le modifiche. In XML, come in tutti i linguaggi più recenti, si possono usare i namespace per evitare i conflitti sui nomi.

Roberto Brunetti (alla console) e Paolo Pialorsi (che si esibisce come breakdancer). Il JS sullo sfondo dovrebbe servire a restituire i campi modificati nel client al database sul server. Dovrebbe.

Per l’ispezione e la modifica W3C raccomanda il Document Object Model (DOM) che fornisce un albero (In-Memory Tree, generato in memoria alla lettura del file XML) per la navigazione negli oggetti rappresentati da XML; per poter raggiungere contenuti XML dalle pagine HTML sono state inventate le cosiddette Data Island; poi esistono strumenti di filtraggio, ricerca e collegamento di risorse e contenuti.

XML nasce con l’ambizione di unificare gli infiniti schemi per la rappresentazione dei dati nelle moderne piattaforme connesse in rete. In pratica permette di trasferire dati su protocolli standard per il formato ASCII, e può rappresentare il trait d’union tra le varie tecnologie attualmente in uso. Ma senza XSLT sarebbe semplicemente un altro dei dialetti e delle convenzioni di codifica. XSLT praticamente è un linguaggio funzionale (anzi, basato sui “functoid”) che permette di descrivere trasformazioni strutturali, è XML, e quindi permette di leggere una documento DOM e trasformarlo nel suo analogo in un’altra struttura con nomi di campi e persino campi calcolati diversi.

Grazie a XML possiamo quindi trasferire dati tra client e server (e, grazie a XSLT, anche tra realtà diverse).
E possiamo inserire delle Data Island nelle nostre pagine HTML, effettuando sofisticati binding con le strutture classiche di HTML (come le tabelle, o i campi di input) e con i recordset ADO. Quindi con opportune precauzioni si può pubblicare una pagina HTML collegata con un database sul server, permettere all’utente la modifica e rispedire tutto al server per l’aggiornamento. Tutto con poche righe di intuitivo codice.

Interessante la tabella delle versioni di ActiveX Data Object (ADO) e XML.
ADO 2.1 supporta già XML; in pratica è reso possibile il colloquio tra recordset e XML.
ADO 2.5 (nativa in Windows 2000) aggiunge nuove classi e flessibilità.
ADO 2.6 porta XML anche in SQL Sever 2000.

Non lasciamoci ingannare dai trade mark: XML è supportato perfettamente anche da Apache, Cocoon e Oracle, piattaforme non Microsoft. E Paolo e Roberto lo hanno sottolineato in più di una occasione, conquistando ulteriormente le simpatie della platea…

XML è stato alla base di tutti i discorsi affrontati anche nel resto della giornata, e non si può certo liquidare in una paginetta.
Per un approfondimento su XML sono stati consigliati alcuni link.
W3C Recommendation 6 October 2000
Namespaces in XML
Document Object Model
XML in general
Microsoft
XML Training@Architag


Come già accennato è il trasformismo di XML a renderlo così potente. A cosa potrebbe servire questo “superpotere” (parlando in termini di XMen)? Pensiamo a due ditte che debbano scambiarsi fatture (il famoso B2B che vedremo nel dettaglio dopo): se nei due database gli stessi campi hanno nomi diversi, o se in uno dei due è presente un campo che nell’altro viene invece ricalcolato di volta in volta si rende necessario un protocollo di intesa. XML ha un linguaggio trasformazionale di riferimento che permette la conversione di struttura. Questo linguaggio è eXtesnible Stylesheet Language for Transformations (XSLT).

Un linguaggio a tutti gli effetti, nato nel 1999, supporta ovviamente le variabili, il passaggio dei parametri, i cicli, le funzioni e le condizioni logiche. Cosa permette di fare questo tool meraviglioso? Prende la struttura del documento originario, costruisce il relativo albero, lo visita cercando le informazioni indicate e produce un nuovo documento applicando le regole definite. La visita del documento e il matching con le informazioni cercate si basano su XPath e XSL Filter che potremmo semplicisticamente paragonare, per usare il gergo dei browser, a dei bookmark.

Il partner ideale per questo strumento è Active Server Pages da cui XSLT si può richiamare, utilizzando anche le tecniche di locking del modello Apartment Multithreading per ottenere il caching del documento che ci interessa, evitando il continuo swapping del server. Chiaramente questo limita la scalabilità (perché lega la risorsa alla richiesta utente, gestita da un particolare thread…). Esiste, fortunatamente, la possibilità di usare documenti free threaded, accessibili contemporaneamente da più processi. Ovviamente si ha un miglioramento sostanziale nelle prestazioni (fonti non documentabili parlano del 700%). Ma queste sono problematiche, diciamo così, di ottimizzazione, che vanno tenute in considerazione più tardi nello studio del linguaggio.

Come da un po’ di tempo ripetiamo il futuro del web è wireless. E i dispositivi tascabili hanno esigenze diverse dai PC tradizionali. Per non disperdere il lavoro dei nostri sviluppatori su cento fronti diversi potremmo scegliere di usare XML come riferimento, e creare tanti documenti XSLT quanti sono le possibili sorgenti di richieste che il nostro server deve gestire. Geniale, no? Chiaramente nascono forti dubbi sull’effettiva scalabilità del progetto iniziale tra realtà hardware e software tanto diverse tra loro, ma lavorando in questa ottica sicuramente si possono raggiungere risultati migliori rispetto al passato.

La lunga sessione dedicata a WML (sarebbe WAP, per intendersi… eccolo che rispunta proprio quando tutti lo davano per morto) e a Windows CE si è rivelata interessante più per risvegliarci dai pregiudizi verso questi dispositivi che per insegnarci nuove tecniche. Infatti il mercato può rivelare sempre grandi sorprese cui bisogna prestare attenzione, senza sottovalutare i “giocattoli inutili” e limitati che abbiamo a disposizione al momento. Presto UMTS e Bluetooth dovrebbero portare a livelli più che accettabili le velocità di trasmissione, e quindi permetterci di usare cellulari e palmari per un ampio range di applicazioni finora proibitive. A quel punto le limitate dimensioni dello schermo e la lentezza delle periferiche di input non costituiranno più un problema tanto grave, e scoprire quale film vengano trasmessi nei cinema della città in cui ci troviamo, fare trading on line o sfogliare le news di Punto sarà alla portata di tutti.

Tra l’altro cellulari e palmari sono accompagnati da una serie di gadget veramente cool che facilitano lo sviluppo: emulatori, output redirectors e strumenti di sincronizzazione. Roberto e Paolo ci hanno mostrato il Nokia Wap Client e un tool che permette di visualizzare schermate da HP Jornada sul monitor del PC in un paio di gustose demo. Abbiamo già esaminato su queste pagine le opportunità offerte dalle reti (wireless e wired) con questi dispositivi.

Tra XSLT e le nuove opzioni offerte da ASP.NET sembra che lo sforzo per realizzare pagine (anzi, card) e siti (anzi, deck) WML sia veramente minimo, quindi si può sempre fare, no?


La battuta abbastanza scontata e un po’ idiota serve a introdurre un’idea piuttosto ambiziosa: trasformare Internet in una grossa LAN. Almeno a livello di servizi e object sharing. La prima idea che potrebbe venire in mente sarebbe quella di estendere COM e DCOM al Web, ma l’idea si rivela fallimentare per una lunga serie di motivi, tra cui le possibili falle per la sicurezza (già abbastanza precaria).

Un pochino più elegante e funzionale potrebbe essere l’idea di appoggiarsi a un protocollo come HTTP per far transitare “codice” XML. Questo comporta comunque una serie di problemi, perché nelle comunicazioni tra sistemi e realtà diverse occorre sempre mettersi d’accorodo. L’idea che sta alla base di SOAP è quello di rendere trasparente e universale il meccanismo del passaggio dei parametri nella richiesta e nella risposta. Scegliendo di usare un “linguaggio” comune per le transazioni è poi possibile usare in locale un’ampia gamma di strumenti: insomma, sembra scongiurato il pericolo di dover installare tutti lo stesso sistema operativo.

Per realizzare questo meraviglioso meccanismo abbiamo bisogno di due interfacce, una tra il client e la rete (requester), e una tra la rete e il server (listener). Richiedente e ascoltatore esistono già: XMLHTTP e DOM. Ci occorre uno schema preciso per gestire parametri e risultati. Questo schema viene chiamato Web Service Description Language (WSDL). Ogni sito può descrivere i servizi messi a disposizione tramite questo linguaggio, e si potrebbero localizzare i servizi con un motore di ricerca specializzato: Universal Description Discovery Integration (UDDI), powered by Microsoft, IBM, Ariba…

Le risorse su SOAP:

Soap Toolkit 2.0
Official Web Site
UDDI
UDDI@Microsoft

Tra i riferimenti forniti da Roberto e Paolo (evidentemente preoccupati per le travagliate fasi della nascita della nuova tecnologia, o semplicemente in vena di scherzi) spicca quello dedicato a un parto indolore .
Lo scenario che ci è stato prospettato è quello che vede, in un prossimo futuro, una migrazione dagli standard più diffusi (COM, DCOM, CORBA) verso SOAP, con una gestione dei dati affidata a XML e una directory dei servizi web realizzata tramite SDL.

La conferenzona si è conclusa con Biztalk. Vero uovo di Colombo dello scambio di informazioni B2B (sarebbe a dire tra aziende) ha l’ambizioso obiettivo di risolvere i diversi problemi di integrazione che appesantiscono Internet: l’eterogeneità dei sistemi operativi, dei formati e dei protocolli di livello transport.

Paolo e Roberto in un altro momento della conferenza. Ci hanno mostrato moltissimi esempi e demo per qualcosa che stimo intorno alle 1500 righe di codice in VB, C#, XML, HTML, JScript e altri linguaggi: non male.

XML potrebbe benissimo rappresentare il formato universale per codificare e descrivere le strutture dati.
Grazie a XSLT potrebbe tra l’altro sfruttare le sue capacità di mutaforma e mettere d’accordo le diverse realtà. SOAP invece dovrebbe rappresentare lo standard per i protocolli applicativi.

Biztalk Server 2000 si presenta con due funzionalità principali: l’attitudine alla gestione dei documenti e le long running transactions. Le LRTx sono le operazioni comunemente svolte su Internet in cui tra le varie fasi della comunicazione (invio richiesta, inoltro a terzi, invio risposta, attivazione di componenti e modifiche ai db…) passano periodi di tempo variabili e grandi a piacere.

Nel corso della conferenza sono stati analizzati gli aspetti legati alla gestione dei documenti. Lo sviluppo e il supporto di BizTalk è affidato a BizTalk Steering Committeee. Il compito di questa organizzazione è di raccogliere dati dai vari partner e mantenere un pool di schemi XML standard per i documenti più comuni. Infatti BizTalk riesce nell’ingrato compito di interprete tra diversi linguaggi grazie a un repository che permette la “traduzione” (con l’inevitabile passaggio intermedio per il formato XML) e il routing dei documenti (che vengono indirizzati all’organizzazione giusta).


ASP.NET è la naturale evoluzione di ASP, anzi, il nuovo nome di ASP+.
Active Server Pages si presenta con una nuovissima rivoluzionata livrea: nuovo runtime, servizi nuovi, nuove modalità di sviluppo. Abolisce VBScript e promuove C# (“C sharp”), linguaggio che è stato utilizzato anche per il suo sviluppo. Con una battuta neanche troppo surreale (e che ovviamente meriterà un approfondimento da parte nostra) Roberto ha commentato che “questo rappresenta il colpo di grazia a Java che ormai sta svanendo”.

.NET è stato presentato come “VB for the Web”, nel senso che introduce la programmazione Event-Driven e i Web Form. Può essere compilato, supporta un solo linguaggio per pagina (ma permette di usare i “pagelet”, cioè dei componenti esterni), ed è multi client (DHTML, HTML 3.2, WML, XHTML).

Tra le funzionalità più avanzate ricordiamo la possibilità (ovviamente ereditaria) di generare codice HTML da inviare al client, gestisce la POST HTTP e può “scatenare” eventi server-side. Permette un binding molto spinto con le strutture anche avanzate, fornisce uno schema di separazione del codice dall’interfaccia. In pratica si tratta del classico “code behind” che i programmatori Visual conoscono bene. Chiaramente gestisce il caching delle pagine in modo sofisticato.

L'ormai mitica slide che descrive il Code Behind e le Pagelet che ci permetteranno di programmare le pagine web proprio come programmiamo le nostre applicazioni VB. Ma sarà un bene o un male?

L’installazione di un’applicazione.NET richiede la copia integrale dei file che la costituiscono in una directory. Al primo lancio avverrà la compilazione del codice. Per rimuovere l’applicazione basterà cancellare la directory in cui è stata installata.

Anche la gestione della configurazione avverrà senza complicati accessi al registry: un file (config.web che verrà presto rinominato come web.config) conterrà tutte le informazioni del caso, come i vecchi cari.INI.
Solamente che sarà scritto in XML… ovviamente!

Questo prodigioso file permetterà di scegliere la modalità di autenticazione (tramite Microsoft Passport, tramite cookies, tramite database di utenti, custom…), la modalità di gestione degli errori e del tracing dell’applicazione.

Un complesso sistema di gestione delle sessioni permette di superare le vecchie tecniche basate sui cookies (e quindi lacunose da più di un punto di vista). Grazie a particolari servizi (gestori “virtuali” di stato delle sessioni) sarà anche possibile limitare i crash del server, o quanto meno evitare che il crash di una sessione costringa il sistema al reset.


Entrare nel dettaglio di tutti questi diversi schemi e strategie di gestione non è banale, e non abbiamo né lo spazio né la motivazione per farlo. Certamente l’interesse di tutti gli sviluppatori è orientata verso queste novità, e presto ci occuperemo approfonditamente di questi aspetti. Anzi, se c’è qualcuno che ha interessi particolari non esiti a guidarci nella scelta degli argomenti da trattare.

Cosa è emerso da questa giornata di lavoro?

Si sente fortissima la necessità di integrare i servizi offerti dal web, mettendo ordine nel caos attuale. La scelta di protocolli comuni che si appoggino a quelli esistenti senza costringerci a riconsiderare l’intera struttura di internet è ormai necessaria, e le varie proposte esaminate in questa sede con i loro diversi gradi di profondità sembrano molto ragionevoli e potenti.

In fondo tutto il nodo della questione è nella ricerca di universalità: XML (la base) permette di esprimere concetti quali DATI, DOCUMENTO, STRUTTURA. Tutto questo può essere trasportato da HTTP senza problemi, visto che si tratta di formato testo.
Grazie a XSLT possiamo cambiare la struttura dei nostri documenti, adattandola per altri dispositivi, per altre realtà, per altri scopi.
Grazie a SOAP possiamo avvalerci di servizi web dalle fonti più disparate.
Grazie a BizTalk otteniamo il routing e la traduzione dei documenti attraverso le varie aziende iscritte al repository.
Possiamo portare a spasso i nostri dati tramite WML e WindowsCE.
.NET sarà il framework ideale per gestire i nostri client e i nostri server in modo che gestiscano questo complesso ma potente e flessibile scenario.
Si sta tornando alle cose semplici: file ASCII, installazioni e disinstallazioni costituite da copie e cancellazioni di file, file di configurazione testuali. Probabilmente la strada migliore per chi sviluppa.

Grazie alla strategia di interconnessione multilayered che rende tutti gli aspetti della comunicazione via internet compatibili indipendentemente dalla piattaforma avremo la possibilità di scegliere il sistema e le applicazioni che più rispondono alle nostre esigenze e al nostro gusto, senza costosi upgrade e riconversioni. Purché si frappongano tra questo sistema e il resto del mondo i giusti filtri.

Non c’è da illudersi: la rivoluzione non sarà indolore, e non sarà nemmeno economica. E un’altro timore fondato è quello legato all’overhead che XML introdurrà nella gestione degli archivi e delle trasmissioni: esisteranno degli interpreti XSLT ottimizzati, basterà il caching dei vari documenti a rendere le conversioni veloci, la mole di dati in formato testo spediti tramite HTTP (ma anche SMTP, SSL e quant’altro) richiederà nuove tecniche di compressione?
I tecnici dovranno tenersi costantemente aggiornati, lavorare molto per rendere il passaggio ai nuovi standard più veloce possibile. Sempre che lo standard si affermi e non subisca le solite radicali riscritture e interpretazioni non standard (i paradossi, eh).

Terremo d’occhio la letteratura, i siti che si occupano di programmazione e system administration, terremo d’occhio i consorzi, la Sun, la Microsoft, la IBM, Cisco e chiunque altro sarà necessario controllare; tasteremo il polso ai tecnici, chiederemo agli esperti e agli appassionati di oltreoceano per non farci cogliere impreparati.

La Future Web Conference ha rappresentato un momento interessante dal punto di vista tecnico e umano, un momento di crescita culturale e sociale, una parentesi piacevole di cui devo ringraziare gli organizzatori e i partecipanti. Ma è stata anche un’occasione di riflessione sulle nostre origini e sulla strada che stiamo percorrendo.
“Abbiamo più futuro che passato”. Ma chi non riuscirà a gestire il proprio passato addattandosi ai nuovi dictat saprà arrivare al proprio futuro?

Manrico Corazzi

Link copiato negli appunti

Ti potrebbe interessare

07 04 2001
Link copiato negli appunti