CGI significa Common Gateway  Interface e designa una classe di programmi (applicazioni) fatti per funzionare in tandem con un web server. Queste applicazioni prevedono di essere invocate da un web server e restituiscono al medesimo una pagina HTML.

Il web server sarà configurato in modo tale per cui l’applicazione CGI diventa a tutti gli effetti parte dell’URL del sito. Per esempio un URL (in ambiente Windows) del tipo: http://www.miosito.com/cgi-bin/MyCgi.exe invoca direttamente MyCgi.exe (nella directory convenzionale cgi-bin).

Il web server a sua volta restiturà pari pari tale pagina HTML al browser che ha invocato la CGI (cioè ha tentato di “navigare” l’ URL che invoca la CGI), per esempio una stringa come la seguente (EOL=LF, chr(10) o CRLF, (chr(13)+chr(10)):

La stringa viene ritrasmessa al browser chiamante, che la tratterà come una pagina statica. Dal punto di vista del browser che ha emesso la richiesta, ricevere una pagina HTML statica, ovvero il contenuto di un file situato sul server, oppure una pagina creata al momento non fa alcuna differenza: si tratta sempre di un flusso di bytes (uno stream) e verrà processato sempre allo stesso modo.

Come passare parametri alla CGI

Il web server fornisce un ambiente standard di esecuzione per i programmi CGI, completo di un set di variabili d’ambiente. In (x)Harbour possiamo leggere le variabili d’ambiente, conoscendo il loro nome, con l’istruzione GetEnv(“nomevar”). Per prima cosa quindi possiamo ricavare PATH_INFO, QUERY_STRING E CONTENT_LENGTH, variabili d’ambiente che dovrebbero contenere l’URL richiesto dal client, una parte specifica di esso e la lunghezza in bytes dello stream inviato dal client. Il modo più semplice quindi di trasmettere parametri è quello di includerli nell’URL, per esempio:
www.miosito.com/cgi-bin/MyApp.cgi?cheoresono
Si noterà che viene usato il carattere convenzionale “?” per delimitare l’inizio della parte dell’URL che contiene i parametri (la query string). Tutto quello che segue il “?” finisce nella variabile d’ambiente QUERY_STRING.

La CGI prende forma: essa deve quindi esaminare QUERY_STRING e agire di conseguenza. La risposta dovrà essere scritta su STDOUT. (x)Harbour ha la funzione OutStd() (e il comando qout, suo alias) che fa appunto questo. Per esempio:

Procedure main()
cCommand:=getenv("QUERY_STRING")
if .not. empty(cCommand)
do case
case cCommand="cheoresono"
outStd("Content-Type:text/html"+chr(10)+chr(10))
outStd(""Sono le "+time()+"")
...
endcase
endif
return nil

Un altro metodo utilizza specifici elementi HTML, ovvero i FORM. Un form è costituito da un “contenitore” e da un certo numero di controlli. Un form dispone di un METHOD e di una ACTION. I METHOD che ci interessano sono POST e GET, mentre la ACTION conterrà il comando da passare alla CGI. Per esempio: (Nota: questo editor è fatto con Javascript e HTML, quindi se tento di scrivere del codice HTML esso verrà interpretato anziché presentato in forma testuale. Per questo i simboli TAG inizio e fine sono sostituiti da parentesi quadre).

[form action="cgi-bin/MyApp.exe" method="GET" name="myform">Importo:[input type="TEXT" name="IMPORTO" value="100"><br><br> Rate:[input type="TEXT" name="RATE" value="12"><br> [input type="SUBMIT" value=""><br></form>

www.miosito.com/cgi-bin/MyApp.exe?IMPORTO=100&RATE=12, il che porrà in QUERY_STRING “IMPORTO=100&RATE=12″. In pratica il metodo GET è equivalente a un URL. Notare come dal FORM vengano generate coppie di valori del tipo[VARIABILE]=[VALORE] separate questa volta dal carettere “&”.

Se lo stesso FORM usasse il METHOD POST, il risultato sarebbe diverso.

[form action="cgi-bin/MyApp.exe" method="POST" name="myform">Importo:[input type="TEXT" name="IMPORTO" value="100"><br><br> Rate:[input type="TEXT" name="RATE" value="12"><br> [input type="SUBMIT" value=""><br></form>

La nostra CGI potrebbe a questo punto arricchirsi con un ulteriore confronto:

…
IF VAL(GETENV(“CONTENT_LENGTH”))!=0
cStream:=FREADSTR(0)

In questo modo possiamo riconosceer una richiesta POST e leggere lo stream via STDIN, viceversa leggeremo QUERY_STRING.

C’è un altro modo, simile al metodo GET, ovvero utilizzare Javascript per manipolare direttamente il contenuto dell’URL prima di effettuare il submit(). Il risultato sarà simile ad un GET.

I ferri del mestiere

A questo punto ci rendiamo conto di necessitare di qualche funzione specializzata: per esempio se l’URL inserito nel client comprende il carattere(ASCII 32), la Query String conterrà %20, ovvero il carattere “%” seguito dal codice ASCII in esadecimale. Questo vale per tutti i caratteri speciali, per cui ci occorrono un paio di funzioni: hexify() e dehexify() per convertire queste stringhe. Al posto di Qout() definiamo mediante il possente preprocessore di (x)Harbour:

#command cgiout [<xList>] => ([OutStd(),] OutStd(chr(10)))

Questo ci permetterà di stampare su STDOUT aggiungendo alla fine [EOL]. OutStd() infatti si limita a porre in STDOUT i caratteri passati, senza formattazione né EOL (che viene aggiunto invece dai comandi “?” e da “??”).

Dato che, come abbiamo visto, avremo a che fare con streams contenenti coppie separate da “&” a loro volta composte da due elementi separati da “=”, ci occorre una funzione “splitter” che separi una stringa in base a un separatore arbitrario. La funzione estrai(stringa,separatore) restituisce un array con tanti elementi quanti i separatori nella stringa.
Visto poi che tutte le pagine che la CGI dovrà produrre iniziano con “content-type…” ecc. e finiscono con il tag di chiusura, scriviamo le funzioni MakeHTMLHeader() e MakeHTMLBottom() che automatizzano in parte queste operazioni.

Anche l’errorsystem andrà modificato: se vogliamo che i messaggi di errore siano visibili, devono anche loro essere stampati su STDOUT e non visualizzati su schermo.

Con questo armamentario ridotto siamo già in grado di scrivere delle CGI, ma non bisogna farsi illusioni. Ci sono alcune complessità intrinseche nella programmazione di applicazioni CGI. Se leggere uno stream in entrata e scriverne uno in uscita non sono operazioni difficili, tutto quello che sta in mezzo invece lo è. Una difficoltà è ovviamente rappresentata dal fatto che bisogna generare in output codice HTML valido, e quindi una certa conoscenza di HTML è indispensabile. Un’altra difficoltà analoga alla prima riguarda Javascript: è evidente che, a parte applicazioni piuttosto scarne, bisognerà fare uso massiccio di Javascript, il che significa impararsi un nuovo linguaggio, niente meno, e per di più un linguaggio che, anche se apparentemente semplice, è invece un brutto cliente se si vuole cercare il pelo nell’uovo. Però bisogna dire che la situazione attualmente è meno tragica di quanto non fosse qualche anno fa: è vero che Javascript è implementato in modo diverso nei diversi browser, ma la corsa alla standardizzazione ha per fortuna ridotto le distanze. Fino a qualche anno fa era laborioso e complesso, oltre che fonte di innumerevoli dispute nei forum dei programmatori Javascript, produrre script  davvero robusti in grado di funzionare su qualsiasi browser.

Un’altra difficoltà consiste nel dover rivedere il paradigma di programmazione. Chi programma da tempo ha già dovuto affrontare il passaggio da programmazione procedurale a programmazione a oggetti. In entrambi i casi il programma dopo essersi avviato aspetta che l’utilizzatore emetta un comando e rimane in esecuzione svolgendo elaborazioni e/o attendendo altri input. Una CGI peraltro invece viene invocata, fa tutto quello che deve fare e termina. Questo significa che alla successiva chiamata la CGI sarà completamente immemore della chiamata precedente! Ogni invocazione della CGI è una esecuzione-e-termine del programma (ci sono tecniche per mantenere delle sessioni ma non verranno trattate qui).

La conseguenza più notevole è che l’output di una CGI deve essere costituito in realtà da una specie di programma che contiene tutte le istruzioni e i riferimenti per compiere l’operazione successiva. Chi ha visto il film Memento può avere un’idea del meccanismo: il protagonista per un disturbo della memoria vive in una specie di eterno presente. Unica guida sono le scritte che imprime sul suo stesso corpo, cosicché al risveglio saprà che fare. Analogamente il programma dovrà scrivere, nella pagina HTML che genererà, i form (o altro) contenenti i comandi da passare a se stesso corredati dai parametri necessari.

Il sorgente che segue è un omaggio a un bravo programmatore che molti anni fa pubblicò una rivista dal titolo “Clipper Magazine”. In uno dei numeri veniva descritta appunto la tecnica per creare delle CGI con Clipper. Si era nel 1996 o giù di lì e possiamo immaginare quanto fosse rivoluzionaria l’idea. Il fatto che dopo oltre 20 anni i concetti siano ancora validi è notevole. Il programmatore si chiamava Mario Lener e ho voluto conservare nel sorgente i suoi messaggi originali di copyright. In realtà non trovo più i sorgenti originali, per cui riporto uno dei miei esperimenti dell’epoca di diretta derivazione dal sorgente originale di Lener. Ci sono degli elementi “spurii” nel sorgente, come la funzione normalizza() ecc. introdotti da me. Per adesso ignoriamoli.

Il programma viene richiamato da un form, quindi per allestire questo test bisognerà avere il server web funzionante, la pagina HTML con il form al suo posto nella documentroot del web server, un database “ar_cli.dbf” con almeno i campi DITTA,CAP e CITTA in una directory accessibile dal nostro programma (C.\cgidata per esempio) e ovviamente Harbour o xHarbour installati.

Link per il sorgente: Link

I linguaggi xBase si sono affermati come strumento di sviluppo di applicativi gestionali in un’epoca in cui non esisteva il mouse, non esisteva Windows, e gli utilizzatori interagivano con i programmi essenzialmente mediante un monitor monocromatico e una tastiera. Ebbe straordinaria fortuna Clipper, in tutto il mondo, che fu usato da milioni di programmatori (me compreso). Clipper non prevedeva di per sé Windows, ma aveva una struttura aperta, talmente aperta che degli sviluppatori indipendenti crearono un “ponte” tra Clipper e Windows, permettendo così al linguaggio xBase per eccellenza di non morire nel nuovo mondo informatico caratterizzato dalle finestre e dalla grafica. Gli odierni Harbour e xHarbour permettono di compilare senza praticamente modifiche persino i vecchi programmi scritti per DBIII, ma offrono anche un completo ambiente di sviluppo per creare applicazioni dotate di GUI (graphic user interface) e che sfruttano tutte le potenzialità dei moderni sistemi.

In breve, Harbour e xHarbour sono due compilatori in grado di trasformare un listato sorgente xBase in un eseguibile Windows/Linux/et.al. Essi derivano concettualmente da Clipper, di cui accettano linguaggio e sintassi, e replicano ed ampliano la struttura aperta.

Si tratta in realtà di due pseudo-compilatori che trasformano il sorgente (= il programma come lo scrive il programmatore, che è un essere umano e avrebbe terribili difficoltà a scrivere i programmi direttamente nel codice macchina che il computer può digerire) in una sorta di codice intermedio basato su un notissimo, basilare e universale linguaggio di programmazione, il linguaggio C, e poi richiamano un compilatore  C vero e proprio ( compilatore=programma che pre-digerisce i sorgenti e li trasforma in codice macchina) per generare l’eseguibile finale.

La base fornita dal comune denominatore C consente una estrema versatilità del linguaggio, il quale consente di incorporare nei programmi praticamente qualunque cosa, direttamente in linguaggio C o mediante componenti aggiuntivi basati sul C. Ricordo che anche Windows è scritto in gran parte in C, come pure Unix/Linux ecc.

Se qualcuno a questo punto si stesse chiedendo che bisogno ci sia di usare uno pseudo-compilatore C eccetera, e se non sarebbe meglio scrivere i programmi in C direttamente, potrebbe rispondersi da solo con una analogia, chiedendosi per esempio che bisogno ci sia di comprare le scarpe bell’e fatte quando si può benissimo comprare cuoio, gomma, colla e procedere con molta maggiore libertà e soddisfazione personale alla realizzazione delle proprie scarpe su misura.

Come ho detto prima, [x]Harbour e compagnia bella (Alaska xBase, Visual Foxpro, Flagship ecc.)  sono linguaggi “di alto livello” il che non significa che abbiano un rango nobiliare nei confronti dei linguaggi di “basso livello” come il C. Alto e basso livello nel gergo informatico stanno a designare in pratica il loro livello di astrazione rispetto al linguaggio macchina, l’ingestibile (per noi umani) codice binario che è l’unica cosa che in ultima analisi un computer esegue direttamente. Tanto più ci si astrae da queste istruzioni elementari, tanto più alto è il livello. In pratica una singola istruzione in un linguaggio di alto livello corrisponde a centinaia o migliaia di operazioni elementari o di basso livello. In questo modo il programmatore può scrivere meno codice e concentrarsi sulla logica del programma, tralasciando i dettagli. Naturalmente un linguaggio di alto livello non consente un controllo fine delle singole istruzioni o di fare particolari operazioni di dettaglio, allo stesso modo in cui un bulldozer non va bene per rimuovere un centimetro di sabbia da uno scavo archeologico,  ma questo controllo fine, per le applicazioni gestionali, non è necessario più di quanto sia necessario uno spazzolino di tasso per spianare un terreno in edilizia.

[x]Harbour sta ad indicare i due compilatori Harbour e xHarbour. Essi sono alquanto simili, ma questo è comprensibile se si pensa che essi sono in effetti due teste del medesimo… mostro.

La storia di questi compilatori è lunga e riporto qualche approfondimento di carattere “storico” qui.

La Ashton-Tate si era sempre rifiutata di dotare DBIII di un vero e proprio generatore di applicazioni che svincolasse il linguaggio, ossia le procedure, dal DBIII vero e proprio. Sarebbe stato possibile cioè far generare a DBIII dei programmi eseguibili anche su computer su cui DBIII non era stato installato, creando un modulo direttamente eseguibile dal computer ma impossibile o comunque difficilissimo da “spacchettare” per capire cosa c’era dentro. Potevano, ma non vedevano l’interesse a farlo: avrebbero agevolato i programmatori ma a loro interessava solo vendere copie del DBIII, senza rendersi conto che ormai il DBIII doveva la sua fortuna proprio ai programmatori, e almeno una forma di offuscamento del codice o pseudocompilazione o criptazione era essenziale per tutelare il lavoro dei programmatori, che mal tolleravano di dover dare in giro il loro sudato codice in forma non protetta e liberamente copiabile. Il mercato stava cambiando, e sempre meno persone avvertivano la necessità di usare direttamente il DBIII, dato che la disponibilità di software già pronto era vasta e crescente, quindi l’obbligo di comprarlo si riduceva alla necessità di essere in regola con le licenze d’uso ma appariva come una specie di tangente salatissima che si doveva pagare ad Ashton-Tate per poter eseguire programmi scritti per DBIII.

Verso la fine degli anni ’80 un paio di società americane riuscirono a creare dei compilatori in grado di prendere le procedure scritte per il DBIII e trasformarle finalmente in programmi stand-alone che non necessitavano di nessun componente aggiuntivo per essere eseguiti: e fu la rivoluzione.

La Nantucket Corp. presentò Clipper, mentre l’altro prodotto che ricordo si chiamava Quicksilver. La spuntò Clipper, che era facilissimamente disponibile in versione “copia non ufficiale”, accompagnato da una essenziale ma completa documentazione, e dotato anche di alcune funzioni supplementari che rendevano ancora più potente il linguaggio, particolarmente un sistema per collegare Clipper al linguaggio C, rendendolo uno strumento potentissimo in mano sia al programmatore della domenica, che poteva compilare semplici procedure derivate dal DBIII, sia al vero esperto programmatore, che poteva sbizzarrirsi a fare qualunque tipo di applicazione.

La prima preda di Clipper furono i milioni di utilizzatori del DBIII, ormai quasi solo programmatori, che poterono finalmente distribuire i loro programmi in forma di eseguibile stand-alone, da cui era impossibile per l’utilizzatore risalire al sorgente (e quindi effettuare modifiche o aggiunte), e cominciò inoltre ad attrarre programmatori che abbandonavano i linguaggi tradizionali per passare al nuovo linguaggio. Clipper versione S87 era fatto straordinariamente bene. Consentiva di scrivere programmi in multiutenza, era solido come una roccia, quasi privo di bachi, efficiente e relativamente facile da imparare (soprattutto per chi proveniva dal DBIII). La sua parentela con il C non lo rendeva troppo esotico anche per chi proveniva da questo linguaggio, e come abbiamo visto questi programmatori disponevano di tutti gli strumenti per collegare Clipper proprio al C, per cui lo considerarono come una manna dal cielo.

La Nantucket fu acquistata all’apice del successo dalla Computer Associates, che era un colosso del software, quando aveva nel cassetto due prodotti più o meno pronti per il lancio, ossia la versione 5 di Clipper e Visual Object, che avrebbe dovuto costituire l’evoluzione di Clipper nel nuovo mondo informatico che si stava delineando e in cui mouse, finestre ed interfacce grafiche stavano prendendo il posto delle tristi schermate nere del DOS.

CA rilasciò in seguito la versione 5 di Clipper, che era in effetti una ulteriore rivoluzione: il linguaggio era stato reimplementato come un sottoinsieme di qualcosa di assai più vasto che prevedeva adesso anche una gestione ad oggetti, che nel frattempo si stava affermando come nuovo paradigma di programmazione. Il “qualcosa” era molto più chiaramente somigliante al C puro, sebbene conservasse la sua distinta identità. Apparve chiaramente la vera struttura interna del nuovo Clipper, ossia un insieme di centinaia di funzioni distinte, e di un “traduttore” che trasformava le classiche istruzioni DBIII nelle corrispondenti funzioni simil-C. La programmazione ad oggetti e la presenza di centinaia di nuove istruzioni facevano apparire come un piccolo sottoinsieme semplificato il tradizionale linguaggio DBIII, ed in questa fase molti programmatori rimasero costernati e perplessi. Devo ammettere che mi convertii alla nuova versione  di Clipper solo quando raggiunse la versione 5.2, e storcendo il naso.  Mi pare che fosse il 1991.

Nel frattempo Ashton-Tate aveva lanciato il DBIV, che ebbe poca fortuna, ed in seguito tentò di riciclarsi in ambiente Windows con il dBase 5, ma anche questo non ebbe grande successo ed alla fine fallì. Adesso dopo diversi passaggi Visual dBase sopravvive, sviluppato e commercializzato da una piccola società indipendente.

Il prodotto migliore dopo Clipper era probailmente Foxpro, che per certi versi era anzi anche meglio, e la versione per Windows, Visual Foxpro, era probabilmente la miglior implementazione del linguaggio dBase in tale ambiente. E’ in questo periodo quindi che si comincia a parlare genericamente di linguaggi xBase, dato che erano presenti diversi prodotti, tutti basati sul vecchio DBIII ma dotati di varianti e caratteristiche proprie. Il vero problema era comunque come riuscire ad adattare il linguaggio dBase al nuovo ambiente Windows-centrico.

Il linguaggio di Clipper e degli altri prodotti concepiti per l’ambiente DOS si rifà ad uno stile di programmazione che è molto diverso dal funzionamento di Windows (o di altre GUI). La necessità di gestire bottoni, finestre, magari anche più finestre contemporaneamente aperte nello stesso programma, e la necessità di dialogare con Windows portano ad un modello di programmazione chiamato event-driven, cioè pilotato dagli eventi, contrapposto alla programmazione tradizionale, detta procedurale, in cui ogni programma fa in genere una sola cosa per volta secondo una successione prefissata. dBase V e Foxbase avevano risolto a modo loro, tracciando la via e creando le loro versioni del nuovo xBase, dotate di estensioni per la programmazione ad oggetti e di tutta la parte grafica. CA aveva rilasciato Visual Object, il successore di Clipper, innovativo e promettente, sebbene alquanto astruso e pieno di bachi che lo rendevano quasi inutilizzabile.

Intervenne a questo punto Microsoft, che acquistò Visual Foxpro. La mossa apparve come il riconoscimento che Visual Foxpro era il miglior strumento xBase disponibile, e che Microsoft si era decisa ad entrare nell’arena dei linguaggi xBase dalla porta principale. Molti programmatori acquistarono Foxpro (me compreso) serenamente pensando che il linguaggio non sarebbe morto e nuovi rosei sviluppi sarebbero arrivati. Niente di tutto ciò. Ben presto la vera strategia di Microsoft si chiarì: aveva acquistato Foxpro solo per toglierlo di mezzo e indirizzare i programmatori verso le sue alternative proprietarie. Foxpro fu lasciato morire lentamente e attualmente non è più nel catalogo Microsoft. L’ultima release è del 2007.

Ma qualche temerario aveva cominciato a lavorare in modo indipendente su Clipper:  aveva visto la luce infatti Clip4win, estensione che permetteva di collegare Clipper all’ambiente Windows (non ricordo l’autore). All’incirca in quello stesso periodo un certo Antonio Linares, un forte programmatore C con buonissime conoscenze dei meccanismi interni di Windows e che si era innamorato di Clipper, scrisse a sua volta una estensione che chiamò Fivewin. La bellezza e la profondità di Fivewin stanno nella semplicità del linguaggio creato da Linares (e dal suo pard Francisco Pulpòn) per gestire l’ambiente Windows, nella perfetta integrazione delle sue estensioni nel linguaggio esistente e nella fondamentale qualità del suo lavoro. Anche se Fivewin aveva qualche baco, la qualità generale era molto buona ed il costo accettabile: il prodotto ebbe subito successo tra i programmatori.

Ma CA aveva nel frattempo quasi abbandonato Clipper, che rimaneva un compilatore a 16 bit in un mondo dove ci si avviava a grandi passi verso i 32 e poi i 64 bit, e cominciava a soffrire di limitazioni strutturali insormontabili. Fu così che Linares cominciò a sviluppare un compilatore indipendente compatibile con Clipper (e Fivewin naturalmente) in grado di affrontare le sfide del futuro. La sua visione fu grandiosa e lo sforzo personale probabilmente immenso. La grossa novità fu che Harbour (il nuovo compilatore) nasceva come progetto Open Source, cioè di libero utilizzo da parte di chiunque. L’ultima versione che CA rilasciò di Clipper è la 5.3b nel 1997. Le alternative per la comunità di programmatori xBase erano costituite da pochi prodotti proprietari piuttosto costosi, come Alaska xBase++, Flagship, Visual Foxpro e dBase V. Nessuno di questi prodotti sembrava però in grado di raccogliere l’eredità di Clipper. Inoltre il solo Flagship era multipiattaforma, ovvero disponibile sia per il sistema Windows, sia per Linux.

L’idea del compilatore Open Source coagulò un certo numero di programmatori e il sistema cominciò pian piano a prendere piede. Presto fu disponibile la versione per Linux, il che consente ad un programmatore di scrivere un programma e di poterlo compilare ed eseguire senza particolari modifiche nei due ambienti. Ad un certo punto la creatura si rivoltò al suo padrone, se così possiamo dire. Proprio perché era un progetto “libero” un gruppo di programmatori in disaccordo con Linares sulle linee da seguire nello sviluppo del compilatore si separò dal progetto originario dando vita a xHarbour, che sta per extended Harbour (2001). Di xHarbour esistono due versioni, una free ed una a pagamento, mentre di Harbour esiste solo la versione free. I due progetti, Harbour e xHarbour, hanno molto in comune dato che derivano dallo stesso tronco, ma le differenze ci sono e non sono poche.

La situazione attuale vede Harbour come un progetto più vasto e disponibile per molte diverse piattaforme, come Windows, Linux, Mac OS X, MINIX 3, Windows CE, Pocket PC, Symbian, iPhone, QNX, VxWorks, OS/2/eComStation, BeOS/Haiku, AIX (xHarbour supporta in pratica solo Windows e Linux). Mediante il contributo di molti programmatori indipendenti il linguaggio dispone oggi di numerose alternative anche a livello di GUI oltre al citato Fivewin (che rimane comunque nella sua posizione di preminenza) e può collegarsi a SQL server come Oracle, PostgreSQL, MySQL ecc. e sfruttare tutta la potenza degli attuali PC a 32 o 64 bit. Personalmente utilizzo entrambi i compilatori in ambiente Windows e il solo Harbour in ambiente Linux. Lo sviluppo è costante e la comunità di programmatori è in perenne contatto in tutto il mondo mediante forum tecnici di discussione e mailing list.