linux user group brescia

A mio parere quello che serve in questo caso e' un supporto hard-real time...
 Perl e' un linguaggio interpretato e, a mio modesto parere, non e'
 la soluzione ideale per acquisizione dati.. in effetti se le richeste
 sono di tempi di risposta estremamente bassi (vicini al tempo fisico
 necessario per la trasmissione dei segnali dalla scheda) suggerirei di usare
 versioni `speciali' di linux quali RT-Linux... se, d'altro canto, la scheda
 contiene un buffer in grado di immagazzinare le informazioni per almeno 
 .5/1 sec., allora anche lo scheduler realtime posix puo' essere usato
 [e questo e' presente nei kernels standard]
 In ogni caso per cose di questo genere programmare in un linguaggio 
 COMPILATO e' essenziale... in fondo pure sotto dos/win stavate usando
 routines ASM e non la parte visual basic...

Venendo al discorso CGI/scripts... tutto ottimo per gestire un database
 [e qui PERL+un motore tipo MySQL o potsgres potrebbero andare eccellentemente]
 ...un po' meno se la visualizzazione deve essere REALTIME... http infatti
 e' un protocollo basato sull'idea di `pull' dell'informazione e non di
 `push' [checche' microsoft voglia fare credere con gli `active channels'].

Per la visualizzazione e il controllo (ripeto, se serve una risposta quasi
 realtime)  ci sono due possibilita'
 1. scrivere tutto in un linguaggio tipo il C;
 2. utilizzare dei linguaggi interpretati tipo TCL/TK per il disegno del
   modulo di intefaccia+routinges C che si collegano con la parte di
   acquisizione dati...

L'opzione `reload' di netscape secondo me non offre risposte in tempi
 sufficientemente brevi, ma -ancora- tutto dipende dalle esigenze
 specifiche...

lg