Nel momento in cui, nella nostra “carriera” di programmatori QL, oltrepassiamo la fase in cui creiamo semplici programmini ed iniziamo e creare software di una certa complessità, uno dei problemi a cui dobbiamo fare fronte, e’ la necessita’ di rendere il nostro software configurabile.

Quale che sia in tipo di configurazione che vogliamo implementare e’ irrilevante ai fini del problema, sia che si tratti dei colori della finestra in cui il programma opera o impostazioni di sicurezza, il modo di affrontare il problema non cambia.
Ovviamente sono possibili diverse soluzioni, tutte efficaci ma con punti deboli e punti di forza diversi tra loro.
Sta al programmatore cercare di orizzontarsi tra queste diverse scelte filosofiche in funzione delle sue necessita’.
Infatti a necessita’ diverse possono corrispondere soluzioni diverse allo stesso problema.
Abbiamo ipotizzato una serie di sei esigenze principali di uno sviluppatore di software e proveremo successivamente ad
applicarle alle varie metodologie che andremo analizzando.
Analizziamo ora queste necessità.

Mantenimento durante l’upgrade

E’ la necessita’ di un utente di non dover riconfigurare il proprio applicativo ogni qualvolta installi una nuova release, spesso e volentieri ci si dimentica sia di come funzioni il software di configurazione in quanto lo si è utilizzato soltanto una volta, sia di quali siano tutti i parametri che aveva impostato.
La difficoltà nel ricordare questi particolari nascono proprio dallo sporadico utilizzo di queste opzioni.

Intercomunicabilita’ tra applicazioni

Applicativi evoluti sono in grado di aprire autonomamente altri programmi per effettuare operazioni o per utilizzarne
specifiche funzionalità.
Penso ad esempio a The Reader, che utilizza un editor a scelta dell’utente per digitare i messaggi.

Configurazioni multiple

A differenza del mondo lavorativo, dove ogni utente dispone di una postazione a lui riservata, nell’ambito domestico è usuale che piu’ persona accedano allo stesso computer.
Ovviamente non e’ detto che la configurazione ottimale per uno vada bene per gli altri, anzi spesso capita esattamente l’opposto e ogni utente vorrebbe avere una configurazione propria.
Il risultato piu’ diffuso e’ quello di generare prima una serie infinita di piccole discussioni e poi una configurazione “mediata” che di fatto non piace a nessuno.

Portabilita’ tra OS

Agli sviluppatori più evoluti può interessare che la propria applicazione giri su sistemi operativi diversi.
Questo e’ in genere un problema poco sentito nel nostro mondo in cui siamo spesso impegnati a importare programmi da sistemi più diffusi ed evoluti (tipicamente da linux) che a esportare i propri applicativi verso altre piattaforme, dove
con ogni probabilità già esistono concorrenti più completi dello stesso tipo.
Pero’ trovo giusto considerare anche questa ipotesi, per secondaria che sia, per fare un quadro completo della situazione.

Facciamo ora una breve panoramica dei metodi più utilizzati sia sulla nostra piattaforma che non, e proviamo a rapportali alle necessita’ appena descritte.

Alterazione dell’eseguibile.

Alterare il codice eseguibile tramite un programma esterno è il primo metodo apparso sulla nostra piattaforma.
Vi ricordate dei quattro mitici programmi gestionali PSION?
Ebbene, venivano configurati proprio in quel modo grazie ad un programma in SuperBASIC fornito assieme al package.
Diciamo subito che come metodo non e’ un granchè.
Come prima cosa, ogni qualvolta si doveva cambiare qualche parametro occorreva andare a ripescare il programma di
configurazione, (che veniva generalmente tolto per mancanza di spazio) ricordarsi come funzionava e poi intervenire.
Ai limiti questo sistema si possono anche aggiungere limiti eventuali del software di configurazione.
Lo stesso dicasi per poter accedere alle informazioni di configurazione, occorre sempre guardare dentro l’eseguibile.
Questo comporta un altro problema.
Non e’ detto che in release diverse dello stesso programma i punti dell’eseguibile da “patchare” siano gli stessi.
Questo comporta di conseguenza la riscrittura del software di configurazione.

Fileconfig

Fileconfig rappresenta sulla piattaforma QL dell’evoluzione del sistema precedentemente descritto.
Si tratta di un blocco dati scritti in un formato standard che viene inserito in testa al codice eseguibile.
Il blocco non contiene solo i parametri da configurare ma anche una descrizione degli stessi in forma di domanda.
Facciamo un esempio il parametro che contiene il pathname del file di aiuto avra’ accanto anche la descrizione dello
stesso in forma di domanda o di richiesta “Indicare il percorso del file di aiuto:”
Per intervenire sul blocco di configurazione esiste un unico programma che analizzando il blocco e’ in grado di
auto modificarsi in modo da adeguarsi alle specifiche contenute all’intero del blocco.
Il sistema è decisamente più “user friendly” rispetto al precedente.
Infatti e’ sufficiente un unico programma di configurazione per intervenire su tutti i programmi che utilizzano questo
standard.
Non e’ neppure necessaria una grande fatica per imparare ad utilizzarlo, una volta selezionato l’eseguibile da modificare, sara’ il programma stesso, interrogando il blocco di configurazione a fornirvi le domande a cui rispondere.
Rispetto al primo metodo e’ un enorme passo avanti, rimangono tuttavia i problemi di mantenimento delle impostazioni.

C’e’ da dire che la versione commerciale del configuratore, distribuita da Jochen Merz (www.jms.com) e’ in grado di
leggere il blocco di configurazione e di salvarlo su di un file separato e una volta installata la nuova release, di
inserire nel nuovo programma i dati precedentemente salvati.

 Variabili d’ambiente

Un metodo completamente diverso dai precedenti è quello di utilizzare le variabili d’ambiente: ad ogni parametro viene assegnata una variabile d’ambiente diversa che viene letta dl programma.
Questo sistema ci permette di avere una serie di vantaggi rispetto alle soluzioni precedenti.
Prima di tutto ad ogni aggiornamento del software non dobbiamo preoccuparci della riconfigurazione, il programma
si configurera’ automaticamente leggendo le variabili .Le variabili d’ambiente sono pubbliche per cui anche le altre
applicazioni possono leggerne il contenuto.
A cosa puo’ servire?
Facciamo un esempio pratico.
Prima si parlava di The Reader, che utilizza un editor esterno per comporre i messaggi.
Esistono altri programmi che fanno la stessa cosa, ad esempio C68Tools.
Se entrambi i programmi leggessero la stessa variabile d’ambiente, dovessimo cambiare il nostro editor con un altro
(ad es. da QD a MicroEMACS), basterebbe intervenire in un solo punto per aggiornare entrambi gli applicativi.
Altro vantaggio delle variabili d’ambiente e che profili utente diversi, operanti sulla stessa postazione, potrebbero avere valori diversi, consentendo in questo modo ad ogni utente di avere le proprie impostazioni preferite senza interferire con gli altri profili.

File di configurazione separato

Nel caso in cui i parametri risultino essere troppo numerosi conviene evolvere il metodo precedentemente descritto.
Si riduce il numero delle variabili d’ambiente ad una, che verrà utilizzata per il puntamento ad un file di configurazione separato.
In questo modo il programma potra’ accedere egualmente alle informazioni, mantenendo i vantaggi del metodo escritto
prima, ma senza intasare eccessivamente l’elenco delle variabili d’ambiente.
Questo per contro significa che un programma esterno per poter agire su questo archivio dovrà prima conoscerne il formato oltre che il contenuto.

Registro di configurazione.

Un ulteriore passo avanti e’ la creazione di un archivio univoco, gestito dal sistema, che contenga in un formato standard tutte le informazioni relative ad ogni programma presente sulla macchina.
E’ la soluzione adottata da Windows.
Ogni applicativo dovrebbe utilizzare tale registro (ripeto, DOVREBBE!) per inserirvi i propri parametri in modo che siano facilmente accessibili.
La controindicazione e’ che tale registro dovrebbe essere gestito dal sistema operativo, cosa che attualmente nemmeno
SMSQ\E fa.

Esistono poi programmi che gestiscono configurazioni multiple in cui si lascia decidere all’utente quale tipo di configurazione adottare.
Tecnicamente c’e’ ovviamente una priorita’ nelle varie configurazioni, per cui il programma puo’ liberamente decidere
quale di questi mezzi utilizzare.
In questo caso, per evitare doppioni e/o effetti indesiderati e’ sempre consigliabile valorizzare una sola configurazione in
modo da essere certi che il programma in questione legga soltanto questa.

Come potete vedere le scelte possibile sono tante, ognuna con pregi e difetti; ora la scelta e’ solo vostra.

Giorgio Garabello