Trasformare il web in uno strumento di editing collaborativo, o anche in un filesystem distribuito, o forse in un'alternativa al CVS. Con le estensioni WebDAV il protocollo HTTP prende nuova vita ed esplora nuove e imprevedibili applicazioni.
Pubblicato per gentile concessione della casa editrice Infomedia www.infomedia.it.
All'inizio era il World Wide Web, una rete di siti e documenti da
sfogliare e consultare, anche da consultare e trasformare, senza poter
fare molto di più. Certo, fin dall'inizio è stato possibile scaricare,
modificare e ricaricare online pagine html, che nel corso degli anni
sono diventate applicazioni cgi, java applet, pagine dinamiche in asp,
php e mille altre pagine; tutti tentativi di estendere e sradicare
dalla sua staticità quasi monolitica il protocollo.
I tentativi di rendere gestibili i documenti web direttamente online risalgono a ormai più di 10 anni, con il primo prototipo di web browser con capacità di scrittura online, sviluppato da Tim Berneers-Lee, senza contare i protocolli proprietari successivi, implementati, ad esempio in NaviPress della NaviSoft, o nel FrontPage della Vermeers Technologies, nome quest'ultimo reso noto da Microsoft.
Ma siamo sempre allo stesso punto: protocolli proprietari, estensioni non standardizzate in grado di dialogare con applicazioni proprietarie, sorde e mute al resto del mondo.
Lo scenario cambia con la costituzione di un gruppo di lavoro specifico della IETF, dedicato all definizione di una estensione al protocollo HTTP, in grado di trasformare il web da "semplice" catalogo a strumento per l'authoring distribuito asincrono. Dietro a questa serie di parole si nasconde un intento mal celato, ovvero quello di rndere possibile la gestione di dati multimediali direttamente online, il che rende possibile non solo la modifica di pagine web, ma anche di file di ogni tipo, contenuti appartenente, appunto, a media differenti. E con questo abbiamo iniziato a chiarire il significato della prima parte del nome dato allle nuove estensioni, WEBDAV. Nel molento stesso, infatti, in cui rendiamo disponibili per l'editing delle risorse in un ambiente collaborativo, distribuito, è il web è per sua natura distribuito, nasce l'esigenza di gestire tutto questo materiale con un meccanismo di revisioni: che consenta a due "autori" che nel medesimo momento o in momenti differenti (asincrono), si trovino a lavorare sullo stesso documento, con il rischio che le modifiche di uno non integrino, ma sovrascrivino quelle dell'altro.
Le esigenze appena descritte si concretizzano nel 1999 in una proposta contenuta nella RFC 2518 "HTTP Extensions for Distributed Authoring - WEBDAV", nella quale viene introdotta una serie di estensioni standardizzate al protocollo HTTP/1.1, che consentano ai client di effettuare operazioni di authoring remoto.
I tentativi di rendere gestibili i documenti web direttamente online risalgono a ormai più di 10 anni, con il primo prototipo di web browser con capacità di scrittura online, sviluppato da Tim Berneers-Lee, senza contare i protocolli proprietari successivi, implementati, ad esempio in NaviPress della NaviSoft, o nel FrontPage della Vermeers Technologies, nome quest'ultimo reso noto da Microsoft.
Ma siamo sempre allo stesso punto: protocolli proprietari, estensioni non standardizzate in grado di dialogare con applicazioni proprietarie, sorde e mute al resto del mondo.
Lo scenario cambia con la costituzione di un gruppo di lavoro specifico della IETF, dedicato all definizione di una estensione al protocollo HTTP, in grado di trasformare il web da "semplice" catalogo a strumento per l'authoring distribuito asincrono. Dietro a questa serie di parole si nasconde un intento mal celato, ovvero quello di rndere possibile la gestione di dati multimediali direttamente online, il che rende possibile non solo la modifica di pagine web, ma anche di file di ogni tipo, contenuti appartenente, appunto, a media differenti. E con questo abbiamo iniziato a chiarire il significato della prima parte del nome dato allle nuove estensioni, WEBDAV. Nel molento stesso, infatti, in cui rendiamo disponibili per l'editing delle risorse in un ambiente collaborativo, distribuito, è il web è per sua natura distribuito, nasce l'esigenza di gestire tutto questo materiale con un meccanismo di revisioni: che consenta a due "autori" che nel medesimo momento o in momenti differenti (asincrono), si trovino a lavorare sullo stesso documento, con il rischio che le modifiche di uno non integrino, ma sovrascrivino quelle dell'altro.
Le esigenze appena descritte si concretizzano nel 1999 in una proposta contenuta nella RFC 2518 "HTTP Extensions for Distributed Authoring - WEBDAV", nella quale viene introdotta una serie di estensioni standardizzate al protocollo HTTP/1.1, che consentano ai client di effettuare operazioni di authoring remoto.
Sul sito www.webdav.org troverete tutte le risorse per approfondire i temi affrontati in questo articolo
WebDAV, proprietà, risorse e collezioni
A differenza dell'HTTP standard, in cui i parametri dei metodi
utilizzati vengono codificati direttamente ed esclusivamente negli
header, WebDAV utilizza anche XML per encodare i parametri da passare
ai metodi stessi. Ciò consente di estendere la quantità e la qualità
dei metadati che possono essere scambiati fra client e server e di
renderli universalmente fruibili grazie alla capacità dell'XML di
encodare le informazioni utlizzando un set di caratteri ISO 10646.
WebDav introduce nella semantica del web un concetto esteso, quale quello di proprietà, che viene generalmente indicato come un meta dato, ovvero una dato la cui funzione è quella di descrivere lo stato di una risorsa. Non che nel protocollo HTTP non esista già il concetto di proprietà, ma la sua capacità espressiva, all'interno degli header tradizionali si trova a essere decisamente limitata, inadeguata a esprimere la ricchezza di contenuti, di meta dati, in un ambiente di authoring distribuito. Più nel dettaglio, possiamo definire in WebDAV una proprietà come una coppia nome/valore, nella quale il nome identifica una URI che punta a una risorsa e ne fornisce quindi un metodo di individuazione e di accesso, mentre il valore consiste in un frammento XML ben formato. Da notare che la natura stessa di meta linguaggio dell'XML consente di estendere e modificare in maniera aperta il valore di una proprietà aggiungendo, ad esempio, nuovi tag descrittivi. Ciò che risulta evidente è che WebDav si concentra non tanto sul contenuto, ne sulla quali siano i mezzi impiegati per fornirne delle descrizioni, quanto sul metodo con il quale questi contenuti vengono applicati alle risorse.
Proviamo ora, solo per un attimo, a banalizzare i concetti base del WebDAV, operando una stretta analogia con la struttura di un file system, in modo che ci sia agevole introdurre alcune nuove informazioni. Immaginiamo una risorsa web come un file all'interno di un percorso di directory; il file è una risorsa e la directory è una collezione di risorse. Quest'ultima può essere definita essa stessa come una risorsa (in fin dei conti una directory non è che un file), il cui stato consiste di almeno una lista di URI che puntano a risorse appartenenti alla collezione. La stessa URL HTTP può essere definito un namespace gerarchico, la cui profondità viene individuata da caratteri significativi '/', la cui consistenza può essere identificata nella condizione in cui per ogni URL nella gerarchia esista almeno una collezione che contenga quella URL come membro interno, tranne, ovviamente, per la radice del namespace.
WebDav introduce nella semantica del web un concetto esteso, quale quello di proprietà, che viene generalmente indicato come un meta dato, ovvero una dato la cui funzione è quella di descrivere lo stato di una risorsa. Non che nel protocollo HTTP non esista già il concetto di proprietà, ma la sua capacità espressiva, all'interno degli header tradizionali si trova a essere decisamente limitata, inadeguata a esprimere la ricchezza di contenuti, di meta dati, in un ambiente di authoring distribuito. Più nel dettaglio, possiamo definire in WebDAV una proprietà come una coppia nome/valore, nella quale il nome identifica una URI che punta a una risorsa e ne fornisce quindi un metodo di individuazione e di accesso, mentre il valore consiste in un frammento XML ben formato. Da notare che la natura stessa di meta linguaggio dell'XML consente di estendere e modificare in maniera aperta il valore di una proprietà aggiungendo, ad esempio, nuovi tag descrittivi. Ciò che risulta evidente è che WebDav si concentra non tanto sul contenuto, ne sulla quali siano i mezzi impiegati per fornirne delle descrizioni, quanto sul metodo con il quale questi contenuti vengono applicati alle risorse.
Proviamo ora, solo per un attimo, a banalizzare i concetti base del WebDAV, operando una stretta analogia con la struttura di un file system, in modo che ci sia agevole introdurre alcune nuove informazioni. Immaginiamo una risorsa web come un file all'interno di un percorso di directory; il file è una risorsa e la directory è una collezione di risorse. Quest'ultima può essere definita essa stessa come una risorsa (in fin dei conti una directory non è che un file), il cui stato consiste di almeno una lista di URI che puntano a risorse appartenenti alla collezione. La stessa URL HTTP può essere definito un namespace gerarchico, la cui profondità viene individuata da caratteri significativi '/', la cui consistenza può essere identificata nella condizione in cui per ogni URL nella gerarchia esista almeno una collezione che contenga quella URL come membro interno, tranne, ovviamente, per la radice del namespace.
Metodi e intestazioni
WebDAV fornisce allora una serie di metodi per accedere e manipolare
risorse e collezioni di risorse, che si appoggiano sulle strutture
fornite dal protocollo HTTP, come ad esempio i meccanismi di
autenticazione o i layer di criptazione SSL. I nuovi metodi introdotti
possono essere brevemente elencati:
COPY, MOVE
MKCOL
PROPPATCH, PROPFIND
LOCK, UNLOCK
Vengono ovviamente introdotti anche una serie di header che consentano l'interoperabilità fra client e server per l'attuazione dei metodi:
DAV:
IF:
DEPTH:
OVERWRITE:
DESTINATION:
LOCK-TOKEN:
TIMEOUT:
STATUS-URI:
Vediamoli più in dettaglio, partendo dagli header:
DAV:
Questo header indica che la risorsa referenziata supporta le estensioni WebDAV. Tutte le risorse che supportano DAV devono ritornare un header DAV in seguito a una richiesta di tipo OPTIONS:. Il valore di DAV: è costituito da una lista di classi di aderenza alle specifiche DAV cui è conforme la risorsa richiesta.
IF:
L'header if ha lo stesso significato dell'header HTTP if-Match e viene utilizzato con una URI che rappresenti una informazione circa lo stato di una risorsa.
DEPTH:
Utilizzato con metodi eseguiti su risorse che potrebbero contenere altre risorse, consente di indicare la "profondità" cui va applicato. Depth: 0 applica il metodo alla sola risorsa puntata dalla URI, Depth: 1 alla risorsa e ai suoi immediati discendenti, Depth: inifinity alla risorsa e a tutti i suoi membri, su qualsiasi livello discendente.
OVERWRITE:
Indica se il server debba o meno sovrascrivere lo stato di una risorsa di destinazione non nulla durante l'applicazione dei metodi COPY o MOVE.
DESTINATION:
Questo header specifica l'URI che identifica una risorsa di destinazione per metodi quali COPY e MOVE, che accettano come parametri una URI di partenza e una di destinazione.
LOCK-TOKEN:
Utilizzato con il metodo UNLOCK identifica il lock da rimuovere su una risorsa.
TIMEOUT:
I client possono inserire un TIMEOUT header nelle loro richieste di LOCK su una risorsa. Da notare che il server non è costretto né a onorare né a considerarla. Un header TIMEOUT non può essere utilizzato al di fuori dell'applicazione di un metodo LOCK.
STATUS-URI:
Utilizzato nelle risposte del server per informare il client circa lo status di una URI, ritornando come argomento i codici di status standard del protocollo HTTP.
Ora passiamo ad analizzare brevemente i metodi applicabili alle risorse:
COPY, MOVE: Copia e sposta delle risorse, questo metodo fa uso dell'header DEPTH: per determinare la profondità di applicazione e dell'header DESTINATION: per identificare la risorsa di destinazione. Opzionalmente può fare uso dell'header OVERWRITE:.
MKCOL: Crea nuove collezioni di risorse.
PROPPATCH: Viene utilizzato per impostare, modificare o cambiare le proprietà su una singola risorsa.
PROPFIND: Recupera una o più proprietà su una o più risorse. Utilizzando questo metodo un utente può scoprire quali file sono presenti in una collezione; è consigliabile utilizzare i meccanismi di autenticazione forniti dal protocollo HTTP per proteggere l'accesso a questo metodo.
LOCK, UNLOCK: Aggiunge o rimuove lock sulle risorse, Utilizzano gli header LOCK-TOKEN:.
MKCOL
PROPPATCH, PROPFIND
LOCK, UNLOCK
Vengono ovviamente introdotti anche una serie di header che consentano l'interoperabilità fra client e server per l'attuazione dei metodi:
DAV:
IF:
DEPTH:
OVERWRITE:
DESTINATION:
LOCK-TOKEN:
TIMEOUT:
STATUS-URI:
Vediamoli più in dettaglio, partendo dagli header:
DAV:
Questo header indica che la risorsa referenziata supporta le estensioni WebDAV. Tutte le risorse che supportano DAV devono ritornare un header DAV in seguito a una richiesta di tipo OPTIONS:. Il valore di DAV: è costituito da una lista di classi di aderenza alle specifiche DAV cui è conforme la risorsa richiesta.
IF:
L'header if ha lo stesso significato dell'header HTTP if-Match e viene utilizzato con una URI che rappresenti una informazione circa lo stato di una risorsa.
DEPTH:
Utilizzato con metodi eseguiti su risorse che potrebbero contenere altre risorse, consente di indicare la "profondità" cui va applicato. Depth: 0 applica il metodo alla sola risorsa puntata dalla URI, Depth: 1 alla risorsa e ai suoi immediati discendenti, Depth: inifinity alla risorsa e a tutti i suoi membri, su qualsiasi livello discendente.
OVERWRITE:
Indica se il server debba o meno sovrascrivere lo stato di una risorsa di destinazione non nulla durante l'applicazione dei metodi COPY o MOVE.
DESTINATION:
Questo header specifica l'URI che identifica una risorsa di destinazione per metodi quali COPY e MOVE, che accettano come parametri una URI di partenza e una di destinazione.
LOCK-TOKEN:
Utilizzato con il metodo UNLOCK identifica il lock da rimuovere su una risorsa.
TIMEOUT:
I client possono inserire un TIMEOUT header nelle loro richieste di LOCK su una risorsa. Da notare che il server non è costretto né a onorare né a considerarla. Un header TIMEOUT non può essere utilizzato al di fuori dell'applicazione di un metodo LOCK.
STATUS-URI:
Utilizzato nelle risposte del server per informare il client circa lo status di una URI, ritornando come argomento i codici di status standard del protocollo HTTP.
Ora passiamo ad analizzare brevemente i metodi applicabili alle risorse:
COPY, MOVE: Copia e sposta delle risorse, questo metodo fa uso dell'header DEPTH: per determinare la profondità di applicazione e dell'header DESTINATION: per identificare la risorsa di destinazione. Opzionalmente può fare uso dell'header OVERWRITE:.
MKCOL: Crea nuove collezioni di risorse.
PROPPATCH: Viene utilizzato per impostare, modificare o cambiare le proprietà su una singola risorsa.
PROPFIND: Recupera una o più proprietà su una o più risorse. Utilizzando questo metodo un utente può scoprire quali file sono presenti in una collezione; è consigliabile utilizzare i meccanismi di autenticazione forniti dal protocollo HTTP per proteggere l'accesso a questo metodo.
LOCK, UNLOCK: Aggiunge o rimuove lock sulle risorse, Utilizzano gli header LOCK-TOKEN:.
Abbiamo visto che l'applicazione dei metodi WebDAV ricorda molto da
vicino alcune operazioni su filesystem che ci sono decisamente
familiari e come le operazioni su file, riflettono sulle risorse alcune
caratteristiche. Ad esempio, i metodi COPY e MOVE copiano o spostano
delle risorse all'interno del namespace di una collezione: ma cosa
succede alle proprietà inerenti alle risorse che subiscono questi
metodi? Dipende. WebDAV ci offre due differenti tipi di proprietà,
definite live e static: le proprietà static mantengono il proprio
valore fino a quando questo non viene esplicitamente modificato da un
client, mentre le proprietà live sono gestite dal server e possono
variare in ogni momento. Facciamo un esempio pratico, tanto per
intenderci. Ad esempio, in uno scenario di authoring condiviso potremo
decidere come gruppo di autori di modificare un file posto sul server,
editandolo. In questo caso, a esempio, la proprietà di lunghezza del
file può essere definita di tipo live, dato che questa viene
automaticamente aggiornata con l'aggiornarsi della versione del
documento presente sul server, mentre la proprietà che definisce
l'autore del documento può essere modificata direttamente dall'autore
che ha apportato la modifica, quindi esplicitamente e da lato client e
può essere definita di tipo static.
Ma porre una risorsa in un ambiente altamente collaborativo pone un altro problema, ovvero la possibilità di accedere in maniera concorrenziale alla risorsa stessa. WebDAV fornisce un tipo generale di lock che è esclusivamente in scrittura e influisce direttamente su quei metodi che consentono la modifica dello stato di una risorsa, o una intera collezione (COPY, MOVE, MKCOL, PROPPATCH, PUT, POST, DELETE), mentre non contempla una restrizione su metodi quali PUT o PROPFIND. Vi è da aggiungere inoltre, una proprietà di tipo live, su una qualsiasi risorsa, può cambiare durante il periodo di validità di un LOCK, al contrario di una proprietà static, il cui cambiamento deve essere forzato dal client che possiede il LOCK sulla risorsa. Da ciò risulta evidente una considerazione: l'ambito di validità del metodo coinvolge l'intera risorsa, compresa di proprietà e payload e il metodo blocca la possibilità di alterare sia l'una che l'altra. Da notare che una richiesta di applicazione di questo metodo su una risorsa, a qualsiasi livello della sua gerarchia, deve contenere un request body XML che contenga l'informazione sul proprietario del LOCK stesso, a meno che il metodo non sia altro che un aggiornamento di una precedente richiesta. Altro aspetto da evidenziare è che risalendo nella gerarchia delle risorse, arrivando a una collezione, la prevenzione di un qualsiasi cambiamento di stato da parte di un LOCK include la possibilità di aggiungere o rimuovere membri della collezione stessa, fino a quando non viene applicato un metodo di UNLOCK o scada. Sebbene abbiamo accennato a un unico metodo, dobbiamo entrare ora maggiormente nel dettaglio e individuare due diverse tipologie: esclusivo o condiviso. Un LOCK esclusivo riserva al solo client che lo ha richiesto la possibilità di modificare lo stato della risorsa. Risulta evidente il limite di una tale tipologia di privilegio in un ambiente ad accesso concorrente: esclude la possibilità che altri possano modificare la risorsa fino a quando il lock non venga rimosso dal proprietario, dall'amministratore o cada in timeout. Con un lock condiviso, invece, lo scenario muta con un set di client in posizione di trust reciproco sull'accesso in modifica rispetto alla risorsa condivisa: in questo modo chiunque abbia sufficienti privilegi, garantiti dal proprietario del lock, può agire senza ulteriori limitazioni. Non ci addentreremo in questa occasione, per ovvi motivi di spazio, nelle estensioni di WebDAV dedicate al versioning, che vi invitiamo ad approfondire nella lettura della RFC 3253, ma la direzione in cui si evolve la gestione delle revisioni di una risorsa rende possibile pensare a WebDAV come a una possibile alternativa futura al CVS, adattabile come infrastruttura anche alla gestione delle revisioni documentali o di qualsiasi tipo di media content, senza essere ovviamente più che una struttura, senza la finalità di essere esso stesso uno strumento di gestione.
Ma porre una risorsa in un ambiente altamente collaborativo pone un altro problema, ovvero la possibilità di accedere in maniera concorrenziale alla risorsa stessa. WebDAV fornisce un tipo generale di lock che è esclusivamente in scrittura e influisce direttamente su quei metodi che consentono la modifica dello stato di una risorsa, o una intera collezione (COPY, MOVE, MKCOL, PROPPATCH, PUT, POST, DELETE), mentre non contempla una restrizione su metodi quali PUT o PROPFIND. Vi è da aggiungere inoltre, una proprietà di tipo live, su una qualsiasi risorsa, può cambiare durante il periodo di validità di un LOCK, al contrario di una proprietà static, il cui cambiamento deve essere forzato dal client che possiede il LOCK sulla risorsa. Da ciò risulta evidente una considerazione: l'ambito di validità del metodo coinvolge l'intera risorsa, compresa di proprietà e payload e il metodo blocca la possibilità di alterare sia l'una che l'altra. Da notare che una richiesta di applicazione di questo metodo su una risorsa, a qualsiasi livello della sua gerarchia, deve contenere un request body XML che contenga l'informazione sul proprietario del LOCK stesso, a meno che il metodo non sia altro che un aggiornamento di una precedente richiesta. Altro aspetto da evidenziare è che risalendo nella gerarchia delle risorse, arrivando a una collezione, la prevenzione di un qualsiasi cambiamento di stato da parte di un LOCK include la possibilità di aggiungere o rimuovere membri della collezione stessa, fino a quando non viene applicato un metodo di UNLOCK o scada. Sebbene abbiamo accennato a un unico metodo, dobbiamo entrare ora maggiormente nel dettaglio e individuare due diverse tipologie: esclusivo o condiviso. Un LOCK esclusivo riserva al solo client che lo ha richiesto la possibilità di modificare lo stato della risorsa. Risulta evidente il limite di una tale tipologia di privilegio in un ambiente ad accesso concorrente: esclude la possibilità che altri possano modificare la risorsa fino a quando il lock non venga rimosso dal proprietario, dall'amministratore o cada in timeout. Con un lock condiviso, invece, lo scenario muta con un set di client in posizione di trust reciproco sull'accesso in modifica rispetto alla risorsa condivisa: in questo modo chiunque abbia sufficienti privilegi, garantiti dal proprietario del lock, può agire senza ulteriori limitazioni. Non ci addentreremo in questa occasione, per ovvi motivi di spazio, nelle estensioni di WebDAV dedicate al versioning, che vi invitiamo ad approfondire nella lettura della RFC 3253, ma la direzione in cui si evolve la gestione delle revisioni di una risorsa rende possibile pensare a WebDAV come a una possibile alternativa futura al CVS, adattabile come infrastruttura anche alla gestione delle revisioni documentali o di qualsiasi tipo di media content, senza essere ovviamente più che una struttura, senza la finalità di essere esso stesso uno strumento di gestione.
Goliath è un client grafico DAV-enabled per Mac dalla grafica decisamente user friendly
Conclusioni
Nel momento stesso in cui ci accingiamo a utilizzare uno strumento
sorgono dei quesiti di merito e di metodo. Quanto questo strumento ci
faciliterà il lavoro, quale è il rapporto fra tempo di adattamento e
produttività e quale la diffusione di questa nuova metodologia?
La risposta alla prima domanda è abbastanza semplice e ha un riscontro pratico che l'autore ha sperimentato in ambito aziendale. Sottraendoci alla complessità e versatilità fornite dal WebDAV abbiamo provato ad utilizzare queste estensioni dell'HTTP facendole utilizzare in maniera del tutto trasparente a utenti con un basso grado di educazione informatica, proponendolo come una estensione remota del file system locale delle postazioni di lavoro. Il risultato, sperimentalmente confortante, è stato di un notevole abbattimento degli ostacoli di apprendimento nell'utilizzo di uno strumento utilizzato prevalentemente come un'alternativa a meno conosciuti programmi di upload ed editing remoto di file. In pratica, invece di insegnare a un utente inesperto l'utilizzo di client ftp, addestrarli alle metodiche di editing asincrono delle risorse online, abbiamo proposto le collezioni WebDAV come "cartelle web" da aprire e collocare nelle "Risorse del Computer" di sistemi Windows. In pratica, per un utente inesperto, una cartella qualsiasi del proprio disco, che risiedeva però su un server web. Una sommaria conclusione nel vedere come una cartella web sia stata accettata e utilizzata molto più velocemente e naturalmente di un qualsiasi client ftp user friendly porterebbe a pensare che l'analogia con il file system di un sistema conosciuto, certamente meno sconosciuto di una utility che un utente alle prime armi difficilmente utilizza, ha reso molto più semplice le fasi di apprendimento e la resistenza verso una nuova forma di tecnologia. Stesso risultato si è avuto con utenti di livello leggermente superiori, per i quali si è potuto affrontare a livello superficiale le tematiche di authoring distribuito, che sono risultate meno ostiche e distanti di quanto sarebbe stato prevedibile. Possiamo quindi dire di avere avuto un rapporto decisamente positivo fra tempi di apprendimento e produttività e l'integrazione del DAV all'interno di un sistema operativo ben conosciuto e facilmente accettato ne aumenta le possibilità di utilizzo.
Un'ultima nota sulla diffusione di client DAV-enabled. Abbiamo già citato l'integrazione all'interno delle varie versioni del sistema operativo Microsoft, sia con Internet Explorer 5 che con la suite Office 2000, ma sono presenti client per differenti sistemi operativi, dal davfs, che consente di montare una risorsa remota come se fosse un file system locale a Goliath, un client grafico per Mac, fino a mod_dav, un modulo per Apache che ne abilita il parsing delle estensioni DAV. Per maggiori informazioni sui client che supportano WebDAV vi rimandiamo al sito www.webdav.org, nel quale troverete i link utili a identificare l'applicazione più adatta alle vostre esigenze e una serie di documenti per approfondire i temi trattati in questo articolo.
La risposta alla prima domanda è abbastanza semplice e ha un riscontro pratico che l'autore ha sperimentato in ambito aziendale. Sottraendoci alla complessità e versatilità fornite dal WebDAV abbiamo provato ad utilizzare queste estensioni dell'HTTP facendole utilizzare in maniera del tutto trasparente a utenti con un basso grado di educazione informatica, proponendolo come una estensione remota del file system locale delle postazioni di lavoro. Il risultato, sperimentalmente confortante, è stato di un notevole abbattimento degli ostacoli di apprendimento nell'utilizzo di uno strumento utilizzato prevalentemente come un'alternativa a meno conosciuti programmi di upload ed editing remoto di file. In pratica, invece di insegnare a un utente inesperto l'utilizzo di client ftp, addestrarli alle metodiche di editing asincrono delle risorse online, abbiamo proposto le collezioni WebDAV come "cartelle web" da aprire e collocare nelle "Risorse del Computer" di sistemi Windows. In pratica, per un utente inesperto, una cartella qualsiasi del proprio disco, che risiedeva però su un server web. Una sommaria conclusione nel vedere come una cartella web sia stata accettata e utilizzata molto più velocemente e naturalmente di un qualsiasi client ftp user friendly porterebbe a pensare che l'analogia con il file system di un sistema conosciuto, certamente meno sconosciuto di una utility che un utente alle prime armi difficilmente utilizza, ha reso molto più semplice le fasi di apprendimento e la resistenza verso una nuova forma di tecnologia. Stesso risultato si è avuto con utenti di livello leggermente superiori, per i quali si è potuto affrontare a livello superficiale le tematiche di authoring distribuito, che sono risultate meno ostiche e distanti di quanto sarebbe stato prevedibile. Possiamo quindi dire di avere avuto un rapporto decisamente positivo fra tempi di apprendimento e produttività e l'integrazione del DAV all'interno di un sistema operativo ben conosciuto e facilmente accettato ne aumenta le possibilità di utilizzo.
Un'ultima nota sulla diffusione di client DAV-enabled. Abbiamo già citato l'integrazione all'interno delle varie versioni del sistema operativo Microsoft, sia con Internet Explorer 5 che con la suite Office 2000, ma sono presenti client per differenti sistemi operativi, dal davfs, che consente di montare una risorsa remota come se fosse un file system locale a Goliath, un client grafico per Mac, fino a mod_dav, un modulo per Apache che ne abilita il parsing delle estensioni DAV. Per maggiori informazioni sui client che supportano WebDAV vi rimandiamo al sito www.webdav.org, nel quale troverete i link utili a identificare l'applicazione più adatta alle vostre esigenze e una serie di documenti per approfondire i temi trattati in questo articolo.
Bibliografia
[1] HTTP Extensions for Distributed Authoring - WEBDAV. RFC 2518 - http://www.ietf.org/rfc/rfc2518.txt
[2] Versioning Extensions to WebDAV. RFC 3253 - http://www.ietf.org/rfc/rfc3253.txt
[3] Hypertext Transfer Protocol - HTTP/1.1. RFC 2616 - http://www.ietf.org/rfc/rfc2616.txt
[4] E. James Whitehead, JR., Meredith Wiggins, "WEBDAV: IETF Standard fo Collaborative Authoring on the Web" IEEE Internet Computing, September/October 1998, pagine 34-40 - . http://www.ics.uci.edu/pub/ietf/webdav/intro/webdav_intro.pdf
[2] Versioning Extensions to WebDAV. RFC 3253 - http://www.ietf.org/rfc/rfc3253.txt
[3] Hypertext Transfer Protocol - HTTP/1.1. RFC 2616 - http://www.ietf.org/rfc/rfc2616.txt
[4] E. James Whitehead, JR., Meredith Wiggins, "WEBDAV: IETF Standard fo Collaborative Authoring on the Web" IEEE Internet Computing, September/October 1998, pagine 34-40 - . http://www.ics.uci.edu/pub/ietf/webdav/intro/webdav_intro.pdf
Risorse web
http://www.webdav.org
http://dav.sourceforge.net
| < Prec. | Succ. > |
|---|
