Attenzione ! Questo articolo è molto vecchio e non più attuale. Scalix è da considerarsi un progetto completamente abbandonato.

• OpenSource : Scalix abbandona ?
• Scalix da alternativa ad Exchange a fantasma
• Scalix passa di mano

Sono sempre più numerosi i clienti che incontro che utilizzano Microsoft Exchange all’interno della loro (piccola o media) struttura aziendale. C’è da dire che “utilizzano” non è proprio il termine esatto: spesso mi chiedo, infatti, che diavolo se ne fanno visto che, ad esempio, non sanno nemmeno utilizzare le cartelle condivise, le rubriche condivise, non sanno utilizzarlo per pianificare gli appuntamenti e le riunioni, o, ancora, e sembra comico, non utilizzano Outlook come client per Exchange il che vanifica qualsiasi potenziale vantaggio derivante dall’adozione di questo server. Mi è addirittura capitato di veder installato Exchange (con licenza moooolto dubbia) con un bel POP3 connector che scaricava la posta in locale per poi distribuirla a client Outlook Express connessi …. in POP3 !!! Mi chiedo che diamine di consulente avevano.

Ma a parte questi casi limite in cui Microsoft Exchange è assolutamente inutile, spesso raccolgo mugugni e disapprovazioni rivolte ad Exchange anche in aziende di grosse dimensioni. E’ pesante, è costoso, è difficile da manutenere ecc. ecc.

In generale non mi trovo d’accordo con queste valutazioni soprattutto con riferimento alla pesantezza (e conseguente lentezza) del software. Exchange, a differenza di quello che la stragrande maggioranza dell’utenza crede, non è un mail server: è molto di più ! E, soprattutto, non è un sistema di archiviazione, come del resto non dovrebbe esserlo nemmeno un client di posta. Non si può pretendere di avere Exchange agile e snello se si autorizzano gli utenti a tenere indiscriminatamente archiviati anni e anni di messaggi di posta, con tanto di allegati dalle dimensioni mostruose che sono stati inoltrati in decine di copie a tutti gli utenti interni (i Power Point divertenti sotto le feste sono il peggior cancro per Exchange … sic !). A seconda delle versioni i file di storage hanno dei limiti, le ricerche diventano lente, le manutenzioni su db impiegano giorni … insomma l’interno servizio ne risente.

Sulla difficoltà di manutenzione e configurazione … bè stendiamo un velo pietoso su chi lo afferma. Non vi sono in genere software troppo complessi per chi li ha studiati e sa dove mettere le mani (quello che dovrebbe sapere un responsabile IT che ha dichiarato di saper gestire Exchange) e se si pensa che un groupware come questo debba avere le difficoltà di gestione di wordpad … allora occuparvi di Exchange non è il vostro mestiere.

Costo … argomento scottante specialmente quando si parla di Microsoft vero ? Per i rispettosi delle licenze originali spendere oltre 1.500 Euro per una versione standard che consente solo 5 client simultanei è sicuramente una bella botta. Senza contare gli “oboli” che bisogna versare ogni volta che si vuole incrementare il numero di client e il fatto, non trascurabile, che dovete disporre per forza di un server Windows. Attenzione però : la mia non vuole essere una critica gratuita. La valutazione del costo di un software è operazione che deve andare ben al di là del mero computo dell’esborso iniziale: fattori come la conoscenza del software, l’abitudine all’utilizzo, la compatibilità con applicazioni di altro tipo, l’integrazione, la disponibilità di supporti hardware adeguati ecc. sono tutti elementi che devono pesare nel processo di valutazione. Alla fine il prezzo d’acquisto può risultare confacente alle aspettative o meno: generalmente più sono ampie le dimensioni della struttura più questo valore può risultare giustificato soprattutto in virtù di acquisite esperienze dei reparti IT interni e di un completo utilizzo di tutte le funzionalità del prodotto.

E’ importante però notare che esiste un’alternativa … con i suoi vantaggi e, come in tutte le cose, qualche rovescio della medaglia. Si chiama Scalix ed ha l’ambizioso obiettivo di proporsi come “replacement” di Exchange. L’ho provato e devo dire che non è poi così lontano dai suoi propositi.

Scalix è una piattaforma di collaborazione (così si definisce un groupware) per sistemi operativi Linux. Ed è Open Source il che non vuol dire necessariamente gratuito. Ma quello che risulta più appetibile all’utenza finale è che Scalix può sostituire davvero Exchange: gli utenti che utilizzano Outlook nemmeno si accorgono del fatto che il server è cambiato. Tutto questo rende l’adozione di Scalix particolarmente appetibile specialmente per quelle piccole aziende in cui il fattore budget è particolarmente critico. Con l’equivalente del costo di una licenza Exchange per 5 utenti (solo licenza Exchange !!) vi potrete comprare un discreto server monoprocessore (io ho provato con un IBM X3105 con 80Gb di disco, controller S-ATA e 1Gb Ram) e se siete un ufficio professionale non enorme oppure avete una rete con non più di 25 utenti che usano Outlook, potrete godere di Scalix Community Edition (gratuita … si avete capito bene) spendendo solo … un po’ di tempo.

Si perchè questo è uno dei rovesci della medaglia. Sul server che andrete ad acquistare dovrete montare una delle distribuzioni Linux supportate (Scalix è stata acquisita da Xandros quindi vi consigliano la loro distro che è a pagamento): per il mio (nostro … visto che lo abbiamo fatto in azienda) abbiamo scelto la SuSE OSS 10.1.

La parte più difficile è stata montare SuSE sul server IBM con controller S-ATA: in questo articolo da me redatto sui SuseForums.net spiego come installare OpenSuSE 10.1 su un IBM x206. (mi dispiace ma è in inglese).

Passato questo primo ostacolo (da circa tre anni mi sono cimentato con Linux e mi ritengo ancora un neofita) ho scaricato la versione community di Scalix, decompresso il package e lanciato l’installer.

Prima sorpresa : l’installer è grafico e ti aiuta passo passo a configurare il tuo server. So che gli amanti del nudo e crudo inorridiranno ma … aiutare l’utente non è brutta cosa no ? Tutti i passi di controllo dei prerequisiti sono estremamente chiari e vi aiutano ad individuare quali componenti mancano al vostro sistema: installarli con Yast è poi un gioco da ragazzi.

Terminata l’installazione si passa alla esecuzione della Scalix Admin Console (SAC): un’interfaccia web estremamente intuitiva tramite la quale è possibile creare gli utenti e quindi le mailbox. I tipi di utenti sono 2: standard e premium. I primi (che possono essere infiniti) godranno della connessione ad un normale mailserver dotato di servizi SMTP, POP3 e IMAP. I secondi invece sono i client “privilegiati” che potranno godere di un simil-exchange: supporto MAPI, cartelle condivise, free-busy connector, permessi, deleghe ecc … e chi più ne ha più ne metta. Insomma tutto quello che potreste fare con Exchange Standard. Nella versione Community gli utenti Premium possono essere solo (si fa per dire) 25. E’ un bel passo avanti rispetto ai miseri 5 di Exchange …. no ?

Ok … il server Scalix funziona …. e ora ? Come mi ci collego con Outlook ?

Semplice … bisogna installare sul pc che ospita Outlook lo Scalix Connector per Outlook. Vi dico subito che non è ancora compatibile con Outlook 2007 (il rilascio della versione compatibile è previsto per l’ultimo trimestre 2007). Una volta installato il connettore sarà possibile scegliere, nella configurazione del profilo di Outlook, il servizio server Scalix e, dopo aver inserito nome utente e password ed aver riavviato Outlook …. ohhhhhhhhhh … ma dietro ad OL c’è Exchange ?

Le uniche cose che vi faranno comprendere che state comunicando con Scalix sono per un osservatore attento, una piccola icona animata nella traybar di Windows (è il connettore che dialoga con il server) e per gli altri il fatto che le cartelle standard (Posta In arrivo, Posta In Uscita, Contatti ecc) non sono in italiano ma in inglese (Inbox, Outbox, Contacts ecc). Per tutto il resto vi sembrerà di essere collegati ad un server di Exchange.

Attenzione ! In questo articolo è disponibile per il download il connettore di Scalix 11.4 in lingua italiana.

Potrete creare cartelle condivise, gestire i permessi sulle cartelle, assegnare delegati alla vostra casella postale, schedulare gli appuntamenti invitando gli altri utenti ed avendo visione immediata dei periodi in cui sono occupati o liberi ecc. Insomma tutto quello che vi aspettereste da un “normale utilizzo” di Outlook<>Exchange. Però dietro c’è un server linux e Scalix.

Non vi basta ? Potrete creare regole e filtri per i messaggi a livello di server, potrete assegnare indirizzi email alle cartelle pubbliche (chi non ha un info@nomedominio che devono gestire in tre o quattro … o 50 ?). Quasi tutte le operazioni sono gestibili tramite interfacce grafiche. Molte direttamente dal proprio client outlook, alcune (come ad esempio l’assegnazione degli spazi massimi da concedere ad ogni mailbox, la generazione degli alias per le caselle postali ecc) dall’interfaccia SAC (via Web) e altre (pochissime in verità) solo tramite riga di comando con privilegi di root sul server linux (per esempio l’assegnazione di un indirizzo email ad una cartella pubblica).

Non basta ancora ? Scalix vi offre anche quella che, a mio modestissimo parere, è forse la più funzionale webmail i circolazione. Se non volete installare Outlook o se siete fuori ufficio e volete vedere la vostra posta e i vostri contatti potete utilizzare la SWA (Scalix Web Access) che replica in tutto e per tutto l’interfaccia di outlook.

Insomma … personalmente mi sono innamorato di questo software perchè lo considero davvero un anello di congiunzione tra Windows e Linux … uno di quei software che possono aiutare davvero una struttura IT (dalla piccola alla grandissima) ad avviare una migrazione “morbida” quantomeno dei server da Windows a Linux senza intaccare le funzionalità dei desktop.

Tra l’altro, cosa importante, esiste un connettore Scalix anche per Evolution (solo su Linux) il che permette di avere un groupware a client misti senza necessariamente passare per l’interfaccia web.

In conclusione, per rispondere alla domanda posta dal titolo, posso dire SI, Scalix è una valida alternativa a MS Exchange. Il piano di licencing è molto più economico di Exchange (una versione Small Business da 50 utenti Premium costa meno di 1000 Euro – sapete quanti ne dovete sborsare per Exchange ?) , il server è Linux, non dovrete sospendere il servizio di posta ogni tre per due (ogni volta che arrivano patch per il vostro server Windows dovete riavviare) e vi da tutto quello che può darvi Exchange.

Per contro dovrete spendere un po’ di tempo per imparare qualche cosa di Linux e documentarvi un po’: ma forse questa è una buona occasione per applicarsi ed imparare a capire quello che si fa invece di andare avanti con click click click ok ok. Consideratelo un investimento.

Ecco alcuni link utili

Il sito di Scalix
Scalix Wiki
Il forum della community di Scalix molto attivo

In questi giorni i fervori della politica italiana alzano gli scudi contro l’ordinanza presentata in Parlamento dal giudice Clementina Forleo la quale – meno male – chiede di poter utilizzare le intercettazioni telefoniche, relative alle scalata di Unipol su BNL, nei procedimenti penali.

Scudi alzati, dicevo, perchè tra gli intercettati vi sono esponenti di primissimo piano del nostro palcoscenico politico. Inutile dire che i toni – giudicati da requisitoria – del giudice, non avrebbero avuto la forza di smuovere nemmeno un sassolino se l’intera vicenda coinvolgesse solo comuni cittadini.

Invece, da apparato autoreferente quale è, l’intero nostro arco parlamentare (con ovvio maggiore impegno dei diretti interessati) giudica l’azione della Forleo quale indebita ingerenza nella vita politica italiana, una sorta di supplenza giudiziale con la quale si vorrebbe far sparire una parte importante dell’entourage dirigenziale del nostro governo.

E’ quantomeno singolare che le difese arrivino proprio da quella parte politica che non ha mai smesso di sostenere la validità, la cristallina trasparenza e la inequivocabile correttezza dell’operato della magistratura durante l’intera legislatura precedente. Tuttavia questa non vuole essere una difesa della destra (o centro-destra o come diamine si chiama): non ce ne è bisogno e sarebbe quanto meno inopportuno.

Il problema che vedo e che sempre più mi disgusta è l’eclatante utilizzo di due pesi e due misure nel giudicare l’operato dell’apparato di giustiza: se non ci riguarda o se riguarda l’avversario è tutto corretto, se ci riguarda direttamente allora si tratta di atti indebiti e di accanimento politico. Tutto questo è di uno squallore devastante: non uno dei politici coinvolti ha avuto il buon gusto – quantomeno – se non la correttezza di stare zitto dando seguito alla sempre tanto declamata fiducia nel corso della giustizia. Almeno questo, credo, è dovuto in primis ai cittadini tutti e poi al proprio elettorato di riferimento.

Non mi sognerei nemmeno di chiedere pubbliche ammissioni e scuse da parte degli interessati dal momento che ciò andrebbe direttamente contro al sacrosanto diritto alla difesa garantito ad ogni cittadino, ma almeno un po’ di sane “orecchie basse” potrebbero dare un minimo di credibilità in più ad una dirigenza di stato che ormai ne è quasi completamente priva.  Mi nausea la sola idea che si vogliano attribuire valori sarcastici a battute telefoniche (regolarmente intercettate) con gli attori delle vicende in questione (e poi perchè si telefonavano ? perchè si tenevano informati l’un l’altro ?) perchè la cosa che non riesce ad entrare nella zucca di questi nostri politicucci da 4 soldi (ormai i politicucci del quartierino) è che la loro immagine è la rappresentanza di tutti gli italiani che li hanno eletti, non la loro.

Accettare di essere attori, di primo piano, della vita politica italiana (anzi sarebbe meglio dire ambire, dato che i privilegi garantiti a costoro non configurano certo una scelta di sacrificio) significa mettere se stessi sotto una lente di ingrandimento, sotto osservazione continua da parte della pubblica opinione e, non dimentichiamolo, degli organi che controllano l’osservanza delle leggi in tema di amministrazione della res-publica.

Ed è ancora più scandaloso il fatto che, in assenza di valide motivazioni e giustificazioni che potrebbero rendere quantomeno plausibili (definirli leciti sarebbe troppo) gli atti contestati, si vogliano attribuire al GUP Forleo motivazioni di attacco che nulla hanno a che vedere con le questioni legali in corso di accertamento. Se il giudice non avesse utilizzato quelle espressioni nella documentazione presentata, non avrebbe avuto motivo di presentare alcunchè restando pacifico il fatto che in assenza di fatti penalmente rilevanti il giudice non avrebbe richiesto nessuna autorizzazione a procedere.

Mi rivolgo a Lei, giudice Forleo, formulandole tutti i migliori auguri per un sereno e tenace perseguimento della verità dei fatti: che almeno questa sia un’occasione per certificare la correttezza della nostra politica o, verosimilmente, per farci aprire gli occhi e mandare finalmente questa masnada di parolai … a casa.

Quasi tutti i programmatori che abbiano basato le loro applicazioni web su ASP (VBScript) arrivano prima o poi a porsi seriamente questa domanda nel momento in cui devono partire con un nuovo progetto. La risposta, almeno nel mio caso (o meglio per l’azienda per cui lavoro), non è proprio facile e merita un qualche approfondimento.

Innanzitutto è bene sgombrare il campo da inutili allarmismi riguardanti la prevista morte futura del supporto ASP Classico sulle piattaforme Microsoft. Dal momento che IIS 7.0 supporta ASP classico perfettamente (con qualche accorgimento come spiegato in questo Tips and Tricks for Classic Asp Developers on IIS 7) è lecito pensare che la deadline di ASP classico sarà portata in avanti almeno fino al 2017 il che, rispetto alla data attuale, mette a disposizione un’ulteriore finestra di 10 anni per prendere una decisione.

Il problema quindi si sposta automaticamente sulle differenze di contenuto tecnologico offerte dai due linguaggi, anche se, è bene dirlo, è assolutamente improprio tentare di mettere sullo stesso piano di “linguaggio” le due modalità. Sono infatti profondissime le differenze tra i due e lontanissimi i presupposti su cui si basano.

ASP classico è un linguaggio di scripting: ovvero una sequenza di istruzioni scritte su normalissimi file di testo (modificabili con un qualsiasi editor – a me piace moltissimo Crimson Editor) che vengono interpretati al volo (on-the-fly) da una dll di sistema, la ASP.dll. In quanto tale la sintassi prevista per le pagine ASP (Active Server Pages) è una qualsiasi tra quelle supportate da Microsoft ovvero VBScript, JScript e PHPScript anche se la stragrande maggioranza dei casi di utilizzo prevede l’impiego di VBScript

ASP.NET (aspx), al contrario, è una completa riprogettazione del modello Active Server Pages basato sull’utilizzo del Framework .NET (versione 1 oppure 2): il codice scritto (che può essere implementato nel linguaggio che si ritiene più consono : VB, C#, C++, J#) non è più interpretato ma “tradotto” in un linguaggio intermedio (MSIL – Microsoft Intermediate Language) le cui istruzioni vengono direttamente elaborate dal framework .NET. Molti credono che le pagine ASP.NET siano pagine compilate (ovvero dei binari in linguaggio macchina) ma ciò non è vero e può indurre a conclusioni errate. Il prodotto di compilazione di un codice .NET è, come detto, di fatto una traduzione che ha bisogno comunque di un ambiente di run-time per poter funzionare: il framework .NET appunto. Per i programmatori VB (pre .NET) è immediata l’analogia con lo pseudo-code di VB che necessitava delle librerire VBRun per poter funzionare.

Ma la vera rivoluzione copernicana, di fatto quella che crea i maggiori problemi di approccio ad ASP.NET per i vecchi programmatori ASP, sta nella completa rivisitazione della sintassi e della struttura del codice. Mentre con ASP classico si è abituati a pensare al normale flusso di programma top-down, con ASP.NET bisogna cambiare completamente il proprio approccio alla progettazione ed allo sviluppo: le classi diventano l’oggetto atomico del codice.

In aggiunta a ciò è anche utile osservare che mentre VBScript è una versione light del supporto Visual Basic con un numero molto limitato di funzioni e quasi nessun oggetto nativo (per algoritmi complessi infatti i programmatori devono spesso riferirsi ad oggetti COM esterni), ASP.NET è un VB pieno (oppure un C# pieno ecc) con tutte i modelli di oggetto (e relativi metodi e proprietà) offerti dal framework .NET: in altre parole, e semplificando all’estremo, con i linguaggi .NET praticamente non si ha bisogno d’altro. Per rendere l’idea è un po’ come avere un coltellino svizzero con solo una lama ed un paio di forbici (VBScript) contro un utensile con 5 lame diverse, forbici per la carta e per la plastica, un set completo di brugole, cacciaviti di varia natura, chiavi inglesi e chiavi tubolari, seghe, martelli e chi più ne ha più ne metta ( .NET ). Tutto questo, ovviamente, rende più difficoltoso l’approccio al linguaggio quanto meno sotto il profilo dell’apprendimento mnemonico di tutti gli spazi dei nomi. Come se ciò non bastasse ogni singolo metodo può disporre di diversi override (ovvero modi di invocare il metodo con sequenze di parametri diverse) il che ha reso, nel mio personalissimo caso, praticamente impossibile avvicinarsi alla programmazione .NET senza l’ausilio di un IDE Microsoft con tanto di intellisense: per fortuna Microsoft ha reso pubblicamente disponibili e gratuite le versioni “light” del suo celeberrimo Visual Studio grazie alle versioni Visual Studio Express.

Fatte queste debite e stringatissime premesse, è forse ora di cominciare ad analizzare i perchè di una scelta a favore di ASP Classico o di ASP.NET per l’avvio di un nuovo progetto. Ci tengo però a sottolineare che le domande e risposte che sto per proporvi si basano sull’assunto di un approccio ad un progetto di sviluppo di medio piccole dimensioni: l’analisi di un progetto di grandi dimensioni che abbia tempi di sviluppo e manutenzione molto lunghi, elevate complessità e necessità di integrazione particolarmente articolate, potrebbe (anzi sicuramente richiede) un’analisi completamente diversa.

• ASP non sarà più supportato molto presto: come visto questa affermazione non è vera e anche se non è realistico pensare che una nuova applicazione ASP potrà vivere in eterno, è sicuramente verosimile affermare che il problema, al momento, non si pone.
• ASP.NET è più potente di ASP: in linea di massima ed in via assoluta di principio questo è vero ma nello sviluppo di un progetto conta anche (forse soprattutto) la potenza del team di programmatori. Una squadra ASP già rodata e con diversi progetti alle spalle disporrà certamente di un repository di codice già bello che pronto, testato e rivisto più volte, conosciuto a menadito che li renderà molto spediti nello sviluppo. Al contrario se il team si trova alla sua prima esperienza di sviluppo allora perchè non spendere un po’ di tempo in formazione su .NET ?
• ASP.NET consente uno sviluppo visuale: questo è completamente falso. E’ possibile scrivere applicazioni ASP.NET con un semplice editor di testo anche se si potrebbero incontrare le difficoltà di cui ho detto sopra. Ciò che rende possibile lo sviluppo visuale è Visual Studio (appunto) e nel caso in cui (come vedremo oltre) non sia possibile affidarsi alle versioni Express è necessario prepararsi ad un discreto esborso di denaro per acquisire la versione full. Tra l’altro lo sviluppo visuale non è sempre un bene: il codice generato automaticamente da VS per, ad esempio, un posizionamento assoluto degli oggetti su un form non è proprio il massimo. Preferisco ancora avere il controllo dell’HTML prodotto … anzi dell’intero codice senza routine nascoste.
• ASP.NET è più veloce perchè è compilato: si e no. Innanzitutto abbiamo visto sopra come il prodotto di una compilazione ASP.NET non generi propriamente un binario eseguibile. D’altro canto è anche vero che la velocità di esecuzione di diverse routine è assai più veloce (basti pensare alla concatenazione di stringhe). Eppure mi chiedo … la velocità di una applicazione da cosa è data ? Sono molti i fattori che concorrono. Se pensiamo all’esecuzione del codice server dobbiamo anche pensare al numero di istanze da sopportare ognuna delle quali occupa memoria: un’occupazione di memoria minore (ASP) permette un maggior numero di thread prima che, ad esempio, il sistema inizi a far largo uso della memoria SWAP e quindi a far degradare in generale le performance. Con ASP.NET i processi server che sottendono alla esecuzione del codice .NET sono molto più dispendiosi e quindi raggiungono una massa critica molto prima. Inoltre è bene notare che quasi sempre i punti di criticità maggiore stanno nelle pesanti query sui database che nulla hanno a che vedere con l’adozione di un linguaggio basato su .NET o di scripting.
• Con ASP.NET si usano interfacce AJAX di ultima generazione: vero ma questo si può fare anche con ASP Classico. AJAX è una tecnica mista di codice client e di processi server che dialogano attraverso flussi XML. AJAX non è legato a doppio filo con .NET. E’ vero invece che esistono moltissimi componenti di interfaccia utente (griglie, tabs, combo ecc) implementabili dall’interno di Visual Studio con dei semplici drag-and-drop ma la quantità di codice autogenerato mi piace sempre meno e non sono sicuro che sia ottimizzato per tutte le situazioni.
• Le applicazioni ASP.NET sono compilate e quindi non manipolabili dai clienti: solo parzialmente vero. Programmatori esperti potranno sempre decompilare gli assembly generati. Anche se il vostro cliente non lo farà non è detto che il vostro codice sia al sicuro come in una cassaforte. Inoltre la “compilazione” (e relativo deploy dei soli assembly) comporta, quale rovescio della medaglia, che per fare modifiche anche infinitesimali dovrete sempre avere a disposizione l’intero codice (in ufficio), compilare il tutto, e mandare l’applicazione compilata al cliente. Con ASP classico vi basta notepad dal cliente e … voilà.
• Con ASP.NET si mantiene il controllo di stato: anche con ASP Classico. ASP.NET è solo un modo di produrre codice HTML che verrà interpretato dal browser client. Le comunicazioni HTTP non hanno cognizione di stato. Il solo “valore aggiunto” di ASP.NET in questo ambito è la memorizzazione delle informazioni di stato nel campo nascosto _VIEWSTATE: ad ogni post del form, l’intero contenuto di _VIEWSTATE viene ritrasmesso al server il quale ricreerà la situazione di stato antecedente la richiesta e quindi elaborerà i nuovi dati inviati. E’ un giochino che si può implemetare tranquillamente anche con ASP Classico (ecco qui un bel Framework per ASP Classico).
• ASP.NET fa più scena: parrebbe una considerazione inconsistente ma nella realtà dei fatti è spesso (non sempre) talmente vera da annullare tutti i “contro” elencati fino ad ora.  Un nuovo cliente (poco esperto) sarà sempre benevolmente impressionato dall’adozione di tecnologie di ultima generazione per il solo fatto che … sono di ultima generazione. Fa figo (perdonate l’espressione) sbrodolare che si sviluppa in ASP.NET anzichè in ASP Classico (magari diffamando il caro vecchio ASP che ci ha dato da mangiare per tanti anni): e questo in genere accade ogni volta che non si hanno argomenti a sostegno della bontà della propria applicazione in termini di efficacia e funzionalità.  L’esaltazione della tecnologia adottata mettendo in secondo piano le peculiarità del prodotto è sempre una pessima tecnica commerciale.

Per ora mi fermo qui … ogni commento è bene accetto.