2002 2003 Apache Software Foundation The Rivet Team The Apache Software Foundation

rivet-dev@tcl.apache.org

Fabio Zanotti Italian Translation Italian Linux Documentation Project

zendune@virgilio.it

Questo documento è anche disponibile nelle seguenti lingue: Inglese, Russo Questo documento è basato sulla versione 1.27 dell'originale in inglese.

Apache Rivet è un sistema per la creazione di contenuti web dinamici mediante un linguaggio di programmazione integrato con il Web Server Apache . È progettato per essere veloce, potente ed estensibile, utilizza poche risorse, è facile da imparare e fornisce all'utente una piattaforma che può pure essere utilizzata con altri programmi per lavori da eseguire fuori dal web (GUI, compiti di amministrazione di sistema, elaboratori di testo, gestori di database, XML e così via). Per ottenere questi risultati, è stato scelto il linguaggio di programmazione Tcl da utilizzare unitamente al Web Server Apache. Con questo manuale aspiriamo ad aiutarvi ad iniziare ed a farvi scrivere codice di produzione il più velocemente possibile, dandovi un'idea di come ottenere grandi vantaggi dall'architettura Rivet, finalizzati alla realizzazione di diverse tipologie di siti web. Questa documentazione è un lavoro in corso e, come ogni cosa riguardante Apache Rivet, è Software Libero. Se vedete qualche sezione che necessita di miglioramenti ed avete idee o suggerimenti al riguardo, non esitate a farcelo sapere. Se volete contribuire direttamente, meglio ancora!

Per installare Rivet, avete bisogno di Tcl 8.2 o superiore e Apache 1.3.xx. Può essere eseguito su Linux, FreeBSD, OpenBSD, Solaris e HPUX. È possibile utilizzarlo anche in Windows NT (per cortesia verificate le indicazioni nella distribuzione). Si possono scaricare i sorgenti di Rivet da . Attualmente è il solo modo per ottenere Rivet. In futuro, contiamo di distribuirlo anche direttamente nei formati utilizzati da FreeBSD, Debian, Red Hat e windows. Rivet necessita di alcuni file include (.h) per essere costruito. Il modo più facile per ottenerli, è scaricare il codice sorgente dal server web di Apache, sebbene alcuni sistemi (Debian GNU/Linux per esempio) rendano disponibili per per l'installazione i file header ed altri file di sviluppo. Se intendete costruire Rivet staticamente (compilandolo nel server web Apache, invece di caricarlo dinamicamente), chiaramente necessitate dei sorgenti. Raccomandiamo di costruire Rivet con una libreria caricabile condivisa, per avere la massima flessibilità. Il codice sorgente del server web Apache può essere reperito al seguente link: . Assumiamo, a questo punto, che abbiate installato Apache. Dovrete decomprimere i sorgenti di Rivet nella directory dove vorrete compilarli. gunzip tcl-rivet-X.X.X.tar.gz tar -xvf tcl-rivet-X.X.X.tar.gz Rivet usa un unico sistema di compilazione che abbiamo creato espressamente per questo progetto. Utilizza le informazioni incluse in Apache e Tcl, considerando le loro configurazioni, al fine di compilarlo tramite una serie di script Tcl, che sono ubicati nella directory buildscripts/. Potrebbe essere necessario modificare a mano src/make.tcl, al fine di impostare alcune opzioni. Per prima cosa provate la prossima istruzione e vedete se ha successo. A questo punto, siete pronti ad eseguire la compilazione del sistema: cd src/ ./make.tcl option dove option può essere shared (condivisa) o static (statica). Adesso siamo pronti ad eseguire il comando ./make.tcl install per installare i file risultanti. Questo dovrebbe copiare gli oggetti condivisi (come mod_rivet.so, se è stato creato con successo) nella directory di Apache libexec, come pure installare alcuni script di supporto e codice vario. Rivet è relativamente facile da configurare, cominceremo aggiungendogli il modulo: LoadModule rivet_module /usr/lib/apache/1.3/ mod_rivet.so Questo informa Apache che deve caricare l'oggetto condiviso Rivet, in qualsiasi parte esso risieda sul vostro file system. Ora abbiamo informato Apache su quali file sono del tipo "Rivet" e come elaborarli: AddType application/x-httpd-rivet .rvt AddType application/x-rivet-tcl .tcl Questo informa Apache di elaborare i file con le estensioni .rvt e .tcl come file Rivet. Per altre direttive che Rivet fornisce per la configurazione di Apache, per cortesia, vedete .

Queste direttive sono utilizzate con i file di configurazione del server httpd di Apache per modificare il comportamento di Apache Rivet. Vi sono delle precedenze, come segue: RivetDirConf, RivetUserConf, RivetServerConf, questo significa che DirConf non terrà conto di UserConf, il quale a sua volta non terrà conto di ServerConf. RivetServerConf CacheSize GlobalInitScript ChildInitScript ChildExitScript BeforeScript AfterScript ErrorScript UploadDirectory UploadMaxSize UploadFilesToVar SeparateVirtualInterps RivetServerConf specifica un opzione globale che è valida per l'intero server. CacheSize size Seleziona la dimensione della cache della pagina interna, dove size è il numero di pagine byte-compilate da essere memorizzate per un uso futuro. Il valore predefinito è MaxRequestsPerChild / 5, o 50, se MaxRequestsPerChild è 0. GlobalInitScript script Script Tcl che è eseguito quando ogni interprete viene inizializzato. script è uno script Tcl effettivo; così per eseguire un file, voi eseguireste: RivetServerConf GlobalInitScript "source /var/www/ foobar.tcl" ChildInitScript script Lo script viene valutato quando ogni processo figlio di Apache è inizializzato. Questo è il posto raccomandato per caricare i moduli, creare le variabili globali, aprire le connessioni ad altre applicazioni (quali database) e così via. ChildExitScript script Lo script viene valutato quando ogni processo figlio di Apache termina. Questo è il posto più naturale dove ripulire le risorse create con ChildInitScript. BeforeScript script Lo script viene valutato prima che ogni server abbia fatto l'analisi della pagina (.rvt). Questo può essere utilizzato per creare un'intestazione standard, per ogni istanza. È anche possibile utilizzarlo per caricare codice di cui avete bisogno in ogni pagina, se non volete metterlo in un GlobalInitScript ChildInitScript quando siete al vostro primo sviluppo di un sito web. Questo codice è valutato globalmente e non all'interno del namespace di dove le pagine sono elaborate. AfterScript script Lo script viene chiamato dopo che ogni server ha analizzato la pagina (.rvt). ErrorScript script Quando Rivet incontra un errore in uno script, costruisce una pagina HTML con alcune informazioni circa l'errore e lo script che è stato valutato. Se è stato specificato un ErrorScript, è possibile creare pagine personalizzate di errore. Questo può essere vantaggioso se cercate di assicurarvi che nessun utente possa mai vedere il vostro codice sorgente. UploadDirectory directory Directory ove posizionare i file caricati. UploadMaxSize size Dimensione massima per i file caricati. UploadFilesToVar yesno Questa opzione controlla se è possibile caricare i file in una variabile Tcl. Se avete un limite alla dimensione e non potete usare file di grosse dimensioni, questa soluzione potrebbe essere più conveniente che inviare dati ad un file su disco. SeparateVirtualInterps yes no Se attivo, Rivet creerà un interprete Tcl separato per ogni host virtuale di Apache. Questo è utile in una situazione tipo ISP dove è desiderabile avere un interprete dedicato per ciascun client, cosicché, anche accidentalmente, non possano interferire tra loro. RivetDirConf BeforeScript AfterScript ErrorScript UploadDirectory Queste opzioni sono le stesse di RivetServerConf, ad eccezione che sono valide solo per la directory dove sono state specificate e relative sotto directory. Potranno essere dichiarate nelle sezioni Directory. RivetUserConf BeforeScript AfterScript ErrorScript UploadDirectory Queste opzioni sono le stesse di RivetServerConf, ad eccezione che sono valide solo per la directory dove sono state specificate e relative sotto directory.

var get list exists number all Il comando var recupera le informazioni circa le variabili GET o POST, inviando lo script tramite una richiesta del client. Il trattamento di entrambe le variabili GET e POST è identico, in considerazione delle loro origini. Notate che vi sono due forme aggiuntive di var: var_qs e var_post. Queste due forme restringono le informazioni sui parametri ottenendo rispettivamente la querystring (?foo=bar&bee=bop) o la POSTing. get varname default Ritorna il valore della variabile varname come una stringa (anche se vi sono valori multipli). Se non esiste come variabile GET o POST, viene restituito il valore default, altrimenti viene ritornato "" (una stringa vuota). list varname Restituisce il valore della variabile varname come una lista, se vi sono valori multipli. exists varname Restituisce 1 se varname esiste, 0 se non lo è. number Restituisce il numero di variabili. all Restituisce una lista di nomi di variabili e valori. Vedete . upload channel save data exists size type filename Il comando upload è usato per la manipolazione del caricamento dei file. Vedete le principali direttive di Apache per altri tipi di configurazioni del funzionamento di questa caratteristica di Rivet. channel uploadname Quando date il nome ad un file caricato, uploadname restituisce un canale Tcl che può essere usato per accedere allo stesso file. save uploadname filename Salva uploadname nel file filename. data uploadname Restituisce i dati caricati dal server. Questo è il binario pulito. In altre parole, potrà lavorare anche con file come immagini, eseguibili, compressi e così via. exists uploadname Restituisce 1 se esiste un upload chiamato uploadname. Questo comando può essere utile negli script che si vuole usare nell'elaborazione di più pagine che inviano upload differenti che quindi necessitano di elaborazione specifica. size uploadname Restituisce la dimensione del file caricato. type Se il Content-type è impostato, viene restituito il valore, altrimenti una stringa vuota. filename uploadname Viene restituito il nome del file dell'host remoto che ha caricato il file. names Restituisce i nomi delle variabili, in una lista, di tutti i file caricati. See . load_env array_name Carica l'array delle variabili d'ambiente all'interno dello specificato nome di array. Utilizza l'array ::request::env come valore predefinito. Le pagine di Rivet sono eseguite nel namespace ::request, quindi non è necessario precisare il nome dell'array per più utenti, va bene accedervi tramite env. load_headers array_name Carica gli header che provengono dalla richiesta di un client all'interno del nome dell'array indicato, o usa headers se non è stato indicato alcun nome. load_cookies array_name Carica l'array delle variabili cookie all'interno del nome dell'array indicato. Utilizza l'array cookies come valore predefinito. include filename_name Include un file senza analizzarlo per processare i tag <? e ?>. Questo è il metodo migliore per includere un file HTML o qualsiasi altro contenuto statico. parse filename Come il comando Tcl source, ma analizza pure i tag di elaborazione per Rivet <? e ?>. Utilizzando questo comando, potete utilizzare diversi file .rvt. headers set redirect add type numeric Il comando headers è per l'assegnazione e l'elaborazione di header HTTP. set headername value Assegna in modo discrezionale i valori ed i nomi agli header. redirect uri Redirige dalla pagina corrente ad un nuovo URI. Questo viene fatto nel primo blocco di codice Tcl. add headername value Aggiunge testo all'header headername. type content-type Questo comando assegna l'header Content-type ritornato dallo script, è utile se desiderate inviare, con Rivet, altri contenuti oltre all'HTML (PNG o immagini jpeg, per esempio). numeric response code Assegna un codice di risposta numerico, come per esempio 200, 404 o 500. makeurl filename Crea una URL di riferimento a se stesso dal nome di un file. Per esempio: makeurl /tclp.gif restituisce http://[hostname]:[port]/tclp.gif. Dove hostname e port sono il nome dell'host e la porta del server in questione.

Seguono alcuni esempi sull'uso di Rivet. Si presuppone che conosciate, anche parzialmente, il linguaggio di programmazione Tcl. Se non conoscete molto Tcl, non c'è da preoccuparsi: è semplice e vi sono alcune buone risorse disponibili sul web che vi permetteranno di padroneggiarlo velocemente. A questo proposito, vedete la sezione web sites. Come qualsiasi altro tool, è piacevole vedere qualcosa al lavoro, così andremo a creare una piccola pagina "Hello World". Assumendo che sia stato configurato correttamente Apache, create un file chiamato hello.rvt in una directory dove Apache lo possa trovare, con il seguente contenuto: &hello.rvt; Se poi vi accederete con vostro browser, sarà possibile vedere una pagina nera con il testo "Hello World" (senza apici). In un'altro semplice esempio, genereremo dinamicamente una tabella: &table.rvt; Se leggete il codice, è possibile vedere che è puro Tcl. È possibile mantenere lo stesso codice, eseguirlo fuori da Rivet e generare la stessa pagina HTML! Il risultato sarà qualcosa di simile a questo: In questa sezione mostreremo come accedere alle variabili utilizzando gli operatori GET o POST. Data una form HTML come la seguente: &vars.html; Potete utilizzare questo script di Rivet per ottenere i valori delle variabili: &vars.rvt; La prima istruzione si assicura che la variabile boss sia passata allo script e poi fa qualcosa con quella informazione. Se non è presente, un errore viene aggiunto alla lista degli errori. Nel secondo blocco del codice, la variabile salary è riportata con un'altro errore di controllo, poiché è un numero, è necessario che sia composto da cifre. Alla variabile boss non è richiesto di essere inviata, la setteremo a "Mr. Burns" se non è tra le informazioni ricevute. L'ultimo pezzo del codice di gestione delle variabili è un pezzo ingannatore perché skills è una listbox e può avere, potenzialmente, valori multipli. Opteremo di riceverla come una lista, in modo da poterla riutilizzare. Lo script si assicura che la variabile errlist sia vuota e restituisce un messaggio di ringraziamento. Se errlist non è vuota, viene stampata la lista degli errori riscontrati. Il comando upload fornisce a Rivet la possibilità di accedere ai file trasferiti tramite http come parti di una form "multipart". Per esempio il seguente frammento HTML (upload.html) &upload.html; crea una form con una text input entry associata ad un bottone per l'esplorazione del file system locale. Cliccando sul bottone appare un file browser con il quale l'utente può scegliere il file da inviare (nella text input entry apparirà il path al file scelto). Per essere certi di inviare il contentuto del file è necessario combinare l'azione degli attributi enctype e method nel tag <form...> nel modo specificato nell'esempio. Se non viene fatto la form invierà la definizione del path del file, non il suo contenuto. Nello script invocato nell'azione della form (upload.rvt) i comandi upload argument ... possono essere usati per manipolare i file inviati al webserver &upload.rvt; Non dimenticate che il server Apache deve aver accesso in scrittura nella directory specificata per l'upload. Le direttive di configurazione di Rivet per per l'upload hanno un impatto considerevole sul funzionamento del meccanismo di upload. Controllate la parte della documentazione relativa a queste direttive in modo da scegliere i valori che meglio soddisfano le vostre necessità. E' anche importante capire che alcuni comandi upload sono effettivi se usati in modo mutuamente esclusivo. Apache memorizza i dati in file temporanei che vengono letti da comandi come upload save upload namefilename oppure upload data upload name. Due chiamate successive che si riferiscono allo stesso upload ritornerebbero un file vuoto alla seconda chiamata perchè la prima consumerebbe i dati presenti. In modo analogo la chiamata upload channel upload name ritorna un canale Tcl al file (che può essere usato in funzioni Tcl ordinarie di accesso ai file) solo se non avete già letto o salvato i dati usando rispettivamente upload data upload name o upload save filename In generale mettere un file nelle condizioni di essere scaricato con http è facile quanto stabilire la URI del file stesso e lasciare che i meccanismi di download standard di Apache facciano quello che è necessario. Se un simile approccio è adeguato al vostro progetto non c'è altro da fare che posizionare i vostri file destinati al download in una directory all'interno dell'albero definito dalla DocumentRoot (o in una qualsiasi delle directory che potete configurare con il parametro Alias di Apache o con un Virtual Host) Quando un client invia una uri per scaricare un certo file Apache determina il tipo di contenuto sulla base dell'estensione del file, invia gli header necessari ad informare il client e quindi invia il contenuto stesso del file. Se il client è un browser in grado di rappresentare il contenuto del file questo apparirà all'utente nella finestra del browser stesso. Diversamente, se il browser non ha metodi "builtin" o dei plugin registrati per quel tipo di file, apparirà la tipica finestra di download che chiede istruzioni all'utente. Rivet è però di aiuto nel caso abbiato esigenze più sofisticate. Immaginate per esempio di sviluppare un applicazione web based che raccogliere informazioni di input da passare a programmi esterni o altre procedure Tcl che generano il contenuto di un file a richiesta. In questi casi il file stesso non esiste e non è possibile definire per esso una URI. In altre circostanze il vostro file esiste, ma potreste aver bisogno di inibirne dinamicamente il download e nasconderlo dal web, non solo per i nuovi visitatori del sito, ma anche per quelli che potrebbero aver salvato nei loro bookmarks un riferimento a quel file. Naturalmente potreste eliminare dalle vostre pagine ogni riferimento a quella risorsa (le vostre pagine sono generate dinamicamente, non è vero?) e constestualmente spostare il file in una directory inaccessibile, ma sembra una soluzione tortuosa e poco elegante. Mettere Tcl e Rivet nella condizione di controllare completamente il processo di download aiuta a costruire meccanismi di download più eleganti e sicuri Ecco un esempio di una procedura Tcl che valuta una richiesta di download di un file PDF sulla base del valore di un parametro passato dal client. Il parametro è il nome (senza estensione) del file pdf da scaricare. I file pdf sono tenuti in una directory definita dalla variabile pdf_repository &download.tcl; Prima che il file PDF venga inviato la procedura usa gli header Content-Type, Content-Disposition, Content-Description e Content-Length in modo da informare il client su tipo di file, il nome (proposto) e la sua dimensione. Notate che per impostare il Content-Type Rivet usa una forma specializzata del comando headers. Gli header devono essere inviati prima che i dati siano spediti verso il canale di output. Fare confusione in questo schema causa un errore poichè in quel caso il protocollo stesso viene violato. Altre informazioni sul significato dei "mime headers" nel contesto del protocoll http posso venir trovati alla pagina Il comando headers è fondamentale per generare messaggi in formato XML che devono essere compresi dal codice JavaScript usato in applicazioni Ajax. Ajax è una tecnica di web programming che usa intensamente la capacità di JavaScript (e di altri linguaggi di scripting come VBScript) di manipolare dinamicamente la struttura HTML di una pagina. Nei browser moderni il codice JavaScript può inviare richieste http POST e GET verso il webserver. Queste richieste posso chiedere al webserver di lanciare script (per esempio script Tcl basati su Rivet) che, a loro volta, costruiscono risposte che vengono inviate al browser. JavaScript solitamente usa un handler che gestisce in modo asincrono la comunicazione. Quando un messaggio di risposta viene ricevuto l'handler elabora il contenuto della risposta e modifica il contenuto della pagina corrente con i nuovi dati. Ajax aiuta a sviluppare applicazioni web più pronte e flessibili: invece di passare attraverso il ciclo di richiesta-generazione-trasferimento di un pagina, Ajax permette al programmatore di richiedere e trasmettere solo i dati essenziali, contribuendo così a soddisfare il generale requisito della separazione tra dati e interfaccia utente (risparmiando altresì al server di inviare lo stesso codice html and gli stessi elementi grafici ogni volta che i dati di una pagina vengono aggiornati). Nelle applicazioni Ajax la comunicazione tra client e server viene controllata da una istanza di una classe specializzata che, nel mondo non-IE si chiama XMLHttpRequest, mentre per il mondo IE si chiama ActiveXObject. Attraverso un istanza di questa classe una richiesta tipo GET o POST viene inviata e il server risponde con un messaggio che viene immagazzinato come stringa nella proprietà returnedText dell'instanza di XMLHttpRequest. Nonostante questo canale di comunicazione non implichi affatto che la comunicazione su di esso si effettui con un protocollo specifico, è diventato ampiamente comune sfruttare XML come linguaggio per questi messaggi. Un certo numero di specificazioni di protocollo basate su XML vengono usate per queste applicazioni, tra queste SOAP e XML-RPC (l'ultima è una raccomandazione del consorzio W3C. Comunque sia voi potete inventare anche il vostro protocollo (basato su XML, ma anche in altro formato). E' utile tuttavia sapere che se gli headers http sono opportunamente specificati e se il messaggio di ritorno è scritto in XML well formed, allora anche la proprietà XMLResponse di XMLHttpRequest viene definita con una con un oggetto che è un'istanza di una classe che possiede i metodi e le proprietà dell' XML W3C DOM, permettendo al codice JavaScript di manipolare i dati contenuti nel messaggio con questo modello di DOM. In questo esempio uno script Rivet inizializza un array con i dati essenziali riguardanti alcuni dei maggiori compositori della musica europea. Questo array ha il ruolo di un database che, in una caso reale, può contenere grosse tabelle con migliaia di righe, le quali possono avere dati più completi ed estesi. Lo script è ideato per inviare al client 2 tipi di risposte: un catalogo dei compositori oppure un recordo singolo con le informazioni di un compositore &rivet_web_service.tcl; Per brevità il JavaScript e l'HTML non verranno riportati qui. Possono essere scaricati (assieme allo script Tcl) nell'archivio rivet-ajax.tar.gz archive. Semplicemente aprendo questo archivio in una directory accessibile dal vostro server Apache e puntando con un browser alla pagina rivetService.html dovreste essere in grado di far girare l'esempio. Ogni volta che scegliete il nome di un compositore una nuova query viene inviata e registrata nel log di apache, anche se la pagina html non viene mai ricaricata, ma solo aggiornata con i nuovi dati.

In aggiunta al nucleo del modulo Apache, Rivet fornisce un numero di pacchetti Tcl che includono codice potenzialmente utile. commserver è un package providing a . dio è un database abstraction layer. dtcl è un pacchetto di compatibilità per applicazioni mod_dtcl. form - per creare form. rivet - alcune aggiunte, routine utili. tclrivet

Se non avete trovato la soluzione al problema nella documentazione, la mailing list di Rivet è il primo posto da visitare per ottenere aiuto; spedite un'email a rivet-user@tcl.apache.org. Se avete una domanda, un'idea, o un commento circa il codice di Rivet, per cortesia mandate un'email a rivet-dev@tcl.apache.org. Per iscriversi ad entrambe le liste, mandate un'email a rivet-list-subscribe@tcl.apache.org. Gli archivi delle mailing list sono disponibili a questo indirizzo:

Il newsgroup è un buon posto per porre domande circa Tcl in generale. Gli sviluppatori di Rivet seguono anche il newsgroup, ma è meglio porre domande specifiche su Rivet presso la sua mailing list.

Ci sono diversi siti web che estensivamente trattano di Apache e Tcl. è la casa del progetto Apache Tcl. Andateci per ottenere l'ultima versione del nostro software (se non state leggendo queste pagine fuori dal sito!). è il primo posto da visitare per domande inerenti il web server Apache. è il sito canonico per informazioni su Tcl. è il Tcl'er Wiki, un posto dove poter ricercare domande e risposte di aiuto.

Apache Rivet usa il sistema Apache Bug Tracking presso . Qui è possibile segnalare problemi o verificare se sono già conosciuti e quindi rintracciare pubblicazioni che lo descrivono.

Questa sezione facilmente pare sorpassata, come nuovo codice viene aggiunto, vecchio codice viene rimosso e di conseguenza vengono apportati i relativi cambiamenti. Il miglior posto dove poter verificare se sono state inserite nuove funzionalità è il suo codice sorgente. Se siete interessati ai cambiamenti osservate il FIXME.

Quando Apache è attivo, (o quando i processi figli di Apache sono attivi se un processo Tcl è in uso), Rivet_InitTclStuff viene chiamata, creando un nuovo interprete, o un interprete per host virtuale, dipendentemente dalla configurazione. Inoltre inizializza varie cose, come il canale di sistema RivetChan, crea i comandi Tcl specifici di Rivet ed esegue init.tcl. Il sistema di caching è anch'esso impostato e se c'è un GlobalInitScript, viene eseguito.

Il sistema RivetChan fu creato al fine di avere un canale Tcl reale che potesse redirigere lo standard output. Questo permette di usare, per esempio, il comando normale puts nelle pagine .rvt. Lavora creando un canale che bufferizza l'output e, a tempi predeterminati, lo passa al sistema IO di Apache. Il normale standard output di Tcl è rimpiazzato con un'istanza di questo tipo di canale, in modo che, predefinitamente, l'output venga inviato alla pagina web.

Quando una pagina Rivet viene richiesta, è trasformata in un normale script Tcl tramite l'analisi nel file delle etichette di elaborazione delle istruzioni <? ?>. Ogni cosa fuori da queste etichette diviene un'istruzione estesa puts ed ogni cosa dentro rimane codice Tcl. Ogni file .rvt è valutato nel proprio ::request namespace, in modo che non sia necessario creare e distruggere gli interpreti dopo ogni pagina. Tuttavia, operando nel proprio namespace, ogni pagina non verrà eseguita sporcando le variabili locali create da altri scripts, perché verranno cancellate automaticamente quando il namespace termina, dopo che Apache ha finito di gestire le richieste. Un problema corrente con questo sistema è che, mentre le variabili usano la garbage collection, e quindi vengono distrutte automaticamente quando non sono più usate, i gestori dei file non lo sono: è molto importante quindi che gli autori di script Rivet si assicurino di chiudere tutti i file che hanno aperto. Dopo che uno script è stato caricato ed analizzato dentro una form di "puro Tcl", viene pure immagazzinato, affinché possa essere utilizzato in futuro senza ricaricarlo (e rianalizzarlo) da disco. Il numero degli script immagazzinati in memoria è configurabile. Questa caratteristica può significativamente migliorare l'esecuzione.

Rivet ha rotto con il passato, in quanto noi, gli autori, ci siamo dedicati ad acquisire ciò che preferivamo dalle nostre passate fatiche e tolto o cambiato ciò che non abbiamo più curato. La compatibilità all'indietro non fu un obiettivo primario quando creammo Rivet, ma abbiamo fornito questa informazione che potrebbere essere utilizzata da chi desideri effettuare l'aggiornamento da installazioni mod_dtcl o NWS.

Rivet era originalmente basato su codice dtcl, ma ne è stata cambiata (migliorata !) una parte. I concetti rimangono gli stessi, ma alcuni dei comandi sono cambiati.

TODO