Note su CGI e Win-CGI
Le pagine web hanno potuto diventare interattive alla formalizzazione del protocollo CGI (Common Gateway Interface).
Questo protocollo definisce la modalitá di passaggio dei dati fra il server HTTP e il programma che deve costruire la pagina richiesta in base alle informazioni ricevute.
I mezzi utilizzati per il passaggio di queste informazioni sono costituiti dai canali di STD-IN, STD-OUT e le variabili d'ambiente in quanto, il programma incaricato di costruire la pagina di risposta verrá lanciato dal server HTTP in un processo separato e quindi i canali di comunicazione standard sono la soluzione piú ovvia.
Il pregio di questa soluzione é senz'altro la semplicitá in quanto l'applicazione richiamata puó essere scritta con qualunque linguaggio compilato o interpretato purché supporti lo
scambio di dati tramite i canali standard.
Il difetto é rappresentato dal fatto che deve essere creato un processo apposito per far girare l'applicazione, lanciata l'applicazione, chiuso il processo; questo impone dei
tempi di risposta senz'altro non idonei a server ad altissimo traffico.
Veniamo ora alle specifiche Win-CGI.
In ambiente Windows, é possibile eseguire oltre che codice a 32 bit anche codice a 16 bit.
L'ambiente a 16 bit non é compatibile (ovviamente) a livello di STD-IN e OUT con quello a 32 bit nativo di WIndows.
Questo comporta che, ad esempio, non é possibile far colloquiare IIS di Microsoft con un'applicazione a 16 bit tramite il protocollo CGI classico.
Da quí, ha preso luce la variante Windows del CGI che sostituisce i canali STD-IN, OUT e le variabili d'ambiente con dei files di testo costruiti con l'architettura dei files .INI classici di Windows.
Essi vengono usati da tramite fra il server HTTP e l'applicazione richiamata dopodiché vengono cancellati.
Questa soluzione, se da una parte allarga moltissimo il ventaglio di strumenti utilizzabili per costruire le applicazioni da far colloquiare con il server HTTP dall'altra, introduce ulteriori rallentamenti di tutto il processo dovuti al fatto che tutte le informazioni devono transitare su files che devono essere creati, scritti, letti e cancellati.
Tutto questo evidenzia chiaramente che Win-CGI non è sicuramente un sistema da utilizzare su server ad alto traffico ma, in una intranet aziendale, può avere la sua utilità tenendo conto del fatto che consente il recupero di tutto l'eventuale patrimonio di conoscenze in ambito informatico.
Per Microsoft IIS esiste una DLL (IS2WCGI.DLL) che si preoccupa di fare da tramite fra IIS stesso e l'applicazione richiamata preoccupandosi di creare, scrivere e leggere i files utilizzati per la comunicazione.
Il suo utilizzo é molto semplice, se la nostra applicazione, cha abbiamo provveduto a copiare nella directory "scripts" di IIS si chiama PIPPO.EXE, è sufficiente copiare nella stessa directory una copia di IS2WCGI.DLL chiamandola PIPPO.DLL.
Richiamando dal browser la DLL così rinominata essa provvederá a richiamare l'applicazione con il suo stesso nome passandogli come parametri i nomi dei files da leggere e scrivere che poi essa stessa si preoccuperá di leggere a sua volta, passare a IIS perché ritorni le informazioni contenute al client e cancellare.
Quí di seguito alcune ulteriori informazioni e links per ulteriori approfondimenti.
Specifiche CGI: - http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
Specifiche Win-CGI e utilizzo di IS2WCGI.DLL - Windows CGI 1.3a Interface (Robert Denny) http://www.career-services.uiowa.edu/~wsdocs/32demo/windows-cgi.html - Esecuzione di Windows CGI in Microsoft IIS http://msdn.microsoft.com/workshop/author/script/mspaper.asp http://www.eu.microsoft.com/mind/0596/vbserver/vbserver.htm - Selective Software (ClipWeb) http://www.selective-software.com/cwdoc08.htm - dalla Russia...(é reperibile una copia di IS2WCGI.DLL) http://www.clipper.net.ru/HTMFILES/iis&wcgi.htm - dalla Grecia...una ottima libreria per interfacciare Clipper con il Web http://users.otenet.gr/~maspr/clipper.htm - funzioni clipper http://www.iaw.on.ca/~sfb/clpcgi.html