% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Versionierung im WWW

\chapter{Versionierung im WWW}
\label{Kap. versionierung}
Ausgehend von den Anforderungen an verteilte Informationssysteme im Kapitel~\ref{Kap. AnfInformation}   wird im Folgenden untersucht, welche Bedeutung das Management von Versionen von Ressourcen im Zusammenhang mit Anforderungen wie Konsistenzerhaltung und Redundanzfreiheit f"ur das WWW hat. 

{\em Versionen} sind verschiedene Instanzen einer Ressource (z.B. Text-, Bild-, Audio- oder Videodateien). Es werden zwei Auspr"agungen von Versionen unterschieden \cite{HLS91}: 

\begin{description}
\item[Revisionen:]  Eine Revision ist die Verfeinerung eines existierenden Objektes. In Abbildung~\ref{verNummern} sind die Objekte 1.1 bis 1.4 eine Serie von Revisionen.
\item[Varianten:] Ein Objekt A ist eine Variante eines anderen Objektes B, wenn sich A auf einem zu B parallelen Entwicklungspfad befindet. In Abbildung~\ref{verNummern} ist das Objekt 1.2.1.1\footnote{Die Nummerierung erfolgt in diesem Fall so, da"s es jederzeit m"oglich ist, weitere Varianten zu den Objekten 1.3 und 1.2.1.1 zu erzeugen, deren Nummern dem Schema 1.2.n.1 folgen w"urden, wobei n die n-te Variante zu Version 1.3 bezeichnet.} eine Variante des Objektes 1.3 und eine Revision des Objektes 1.2. 
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=2cm
\epsffile{Bilder/versionierung/verNummern.eps}
\end{center}
\caption{Revisionen und Varianten}
\label{verNummern}
\end{figure}


Versionskontrolle erlaubt die Koexistenz verschiedener Versionen einer Ressource und er\-m"oglicht deren individuelle und vergleichende Visualisierung, sowie ihre automatische oder unterst"utzte Zusammenf"uhrung und Differenzierung \cite{VD95}. Systeme zur Versionskontrolle werden z.B. in der Softwareentwicklung, bei computergest"utzter kooperativer Arbeit (CSCW) oder beim Abgleich verteilter Datenbanken eingesetzt. 

W"ahrend das WWW heute --- mit den technischen Grundlagen HTML 3.2 (vgl. Ab\-schnitt~\ref{html}) und HTTP 1.1 ({\VAS}~\ref{http})  --- ein passives Publikationmedium ist, k"onnen Versionierungssysteme es zu einem aktiven Kooperationsmedium machen, in dem Nutzer nicht nur lesenden sondern auch schreibenden Zugriff auf Dokumente haben. Grunds"atzlich sind zwei Motivationen f"ur Versionskontrolle im WWW erkennbar:

\begin{description}
\item[Passive Benutzer] des WWW m"ochten lesenden Zugang zu verschiedenen Versionen von Objekten haben, wie z.B. Dokumentationen von HTML, HTTP oder SQL Standards. Desweiteren sind Hyperlinks von einem Dokument zu seiner initialen, vorherigen, n"achsten und neuesten Version bei Recherchen "uber die Historie einer Ressource n"utzlich. Von der Implementation eines Versionierungssystems mu"s ein nur lesender Benutzer keine Kenntnis nehmen, da es f"ur ihn in der Regel nicht von Interesse ist, ob die Daten, die f"ur ihn sichtbar sind, in verschiedenen Dateien gespeichert sind oder nach Anforderung durch ihn vor der "Ubertragung zuerst berechnet werden m"ussen.

\item[Entwickler] von WWW Inhalten ben"otigen das Management von Versionen f"ur den Zugang zu Historien von Revisionen oder Varianten einer Ressource, f"ur das parallele asynchrone Bearbeiten von Ressourcen oder als Grundger"ust f"ur den kontrollierten Zugang zu Ressourcen. Editieren z.B. zwei Bearbeiter ein Dokument gleichzeitig, werden die "Anderungen desjenigen, der das Dokument als erster sichert von den "Anderungen des zweiten "uberschrieben und gehen verloren (engl. {\em lost update problem}). Dieses Problem l"a"st sich durch restriktiven Zugang zu Ressourcen --- nur ein Bearbeiter pro Ressource zu einem bestimmten Zeitpunkt --- oder durch das (evtl. automatische) Zusammenf"uhren parallel entstandener Varianten einer Ressource l"osen. 
\end{description}

Bereits Ted Nelson, der im Jahr 1965 mit seinem System {\xanadu} den Begriff Hypertext pr"agte, erkannte, da"s Leser in Hypertextsystemen Verbindungen zu einem Dokument aufbauen, dieses dann "uberarbeitet wird und bei der Ersetzung des alten Dokumentes, die Verbindungen zu diesem Dokument eventuell ung"ultig werden. Aus diesem Grund werden in dem System {\xanadu} Dokumente nie gel"oscht,  auch nicht, wenn neue Versionen eines bestehenden Dokumentes hinzugef"ugt werden \cite{N95}.

Im Zusammenhang mit Hypermediadokumenten, wie man sie im WWW findet, wird Versionierung durch Probleme wie z.B. der Integrit"at von Hyperlinks oder der Konsistenz einer Menge von Dokumenten komplex \cite{HLS91}. Aus diesem Grund wird hier die Versionierung von Daten von der Versionierung von Strukturen getrennt. Dieses Kapitel behandelt die Handhabung mehrerer Versionen einer einzelnen Ressource, w"ahrend in Kapitel~\ref{Kap. kontexte} die Probleme des Konfigurationsmanagement versionierter Ressourcen betrachtet werden, die sich aus versionierten Hypermediadokumenten im WWW ergeben.

In Abschnitt~\ref{verGrundlagen} werden grundlegende Versionierungskonzepte dargestellt. Ziele und Anforderungen der Versionierung im WWW werden in Abschnitt~\ref{verAnf} erl"autert. In Abschnitt ~\ref{verLoesungen} erfolgt die exemplarische Betrachtung verschiedener technischer Realisierungen von Versionierung im WWW.


\section{Terminologie und Konzepte}
\label{verGrundlagen}
Ein {\em Versionierungssystem} ist ein Softwaremodul, das Beziehungen zwischen verschiedenen Instanzen eines Datenobjektes aufrechterh"alt, indem es f"ur Benennung, Speicherung und Retrieval der Instanzen sorgt. Jede Instanz ist eine {\em Version} des Objektes und steht mit den anderen Versionen in einer m"oglicherweise komplexen Struktur aus "alteren, neueren oder parallel entstandenen Versionen in Beziehung \cite{VD95}.

Die Versionierung von Daten bezieht sich auf den Proze"s des Management der Evolution und Entwicklung eines Datenobjektes. Die wesentlichen Konzepte beschreiben dabei das der Evolution zugrundeliegende Datenmodell, die Unterst"utzung kooperativer Arbeit an Datenobjekten sowie die verwendeten Mechanismen zur persistenten Speicherung der Datenobjekte.

\subsection{Datenmodelle}
\label{verDatenmodelle}
Die in Hypermediasystemen zu versionierenden Daten sind in Knoten enthalten, die in verschiedenen Datenmodellen versioniert werden k"onnen. Die Modelle beschreiben, in welchen Beziehungen verschiedene Versionen eines Datenobjektes stehen. Man unterscheidet folgende drei Datenmodelle:

\begin{description}
\item[Lineare Sequenz:]
Versionierung wird im Rahmen einer linearen Sequenz von Revisionen unterst"utzt, d.h. Varianten k"onnen in diesem Modell nicht abgebildet werden.
\item[Baumstruktur:]
Das Modell der Baumstruktur unterst"utzt sowohl Revisionen als auch Varianten und erm"oglicht das parallele asynchrone Editieren von Objekten einerseits durch {\em zeitbasierte Versionierung}, die die Unterschiede zwischen mehreren aufeinanderfolgenden Revisionen eines Dokumentes abbildet, und andererseits durch {\em Autor-basierte Versionierung}, die Modifikationen verschiedener Varianten der selben Version erlaubt.
\item[Gerichteter Azyklischer Graph:]
Dieses Modell bietet neben dem Management von Revisionen und Varianten das 
(evtl. automatische) Zusammenf"uhren (engl. {\em merging}) mehrerer parallel entstandener Versionen von Objekten.
\end{description}

Der Inhalt einer spezifischen Version in allen drei Modellen wird durch die Operationen (z.B. Einf"ugungen und L"oschungen) bestimmt, die auf den Knoten ausgef"uhrt werden, die diese Version mit ihrer Initialversion --- der sogenannten Wurzel ---  verbinden. 

\subsection{Unterst"utzung kooperativer Arbeit}
\label{verCSCW}
Die Unterst"utzung kooperativer Arbeit erfolgt in Versionierungssystemen durch die Verhinderung simultaner Schreibzugriffe auf das gleiche Datenobjekt. Hierzu gibt es zwei unterschiedliche Ans"atze:

\begin{description}
\item[Sperren von Objekten:] Dieser Ansatz ist als {\em checkin/checkout} Prozess bekannt.
Der "Anderungsprozess eines Objektes beginnt mit dem Sperren des Objektes durch den {\em checkout} Prozess f"ur andere Benutzer als den Initiator des {\em checkout}. Nachdem dieser  seine "Anderungen ohne Zugriffskonflikte vorgenommen hat, f"uhrt der {\em checkin} Prozess zur Erzeugung einer neuen Revision des Objektes und die Sperrung wird aufgehoben, so da"s andere Benutzer das Objekt editieren k"onnen. 
\item[Zusammenf"uhren von Objekten:] Dieser Ansatz erlaubt das gleichzeitige Editieren eines Objektes durch mehrere Bearbeiter. Das f"uhrt zu der Erzeugung von Varianten, die in einem {\em merge} Prozess zu einer neuen, allen zusammengef"uhrten Varianten gemeinsamen Revision vereinigt werden. 
\end{description}

Beide Konzepte treten auch in Kombination auf, so da"s falls ein weiterer Bearbeiter versucht, eine gesperrte Ressource zu "andern, er eine Warnung erh"alt, da"s die Ressource bereits in Bearbeitung ist, er aber trotzdem "Anderungen durchf"uhren darf, die dann zu einer Variante f"uhren.

\subsection{Speichermechanismen}
\label{verSpeicher}
Versionierungssysteme speichern keine vollst"andigen Kopien von Revisionen und Varianten von Dateien sondern verwenden Delta-Speicherungstechniken, die nur die Menge der Differenzen aufeinanderfolgender Versionen speichern. Dadurch ist die Menge an benutztem Speicherplatz proportional zu der Menge der an den Dateien vorgenommenen "Anderungen \cite{BB95} und die verschiedenen Versionen sind frei von Redundanzen. Man unterscheidet dabei zwei Verfahren \cite{HLS91}:

\begin{description}
\item[Separate Delta-Dateien:]
Informationen, die ben"otigt werden, um eine Revision in eine andere zu transformieren, werden in separaten Dateien gespeichert. Jeweils eine Datei geh"ort zu einer Revision. RCS --- ein System f"ur die Versionskontrolle von Softwareprojekten --- verwendete fr"uher einen Delta-Mechanismus, der die jeweils aktuellste Revision einer Datei vollst"andig speichert, w"ahrend in den Delta-Dateien die Informationen gespeichert werden, die die Wiederherstellung "alterer Revisionen aus neueren Revisionen erlauben \cite{HLS91}. Heute speichert RCS alle Versionen in einer Archivdatei aus der die spezifischen Versionen bei Bedarf wiederhergestellt werden \cite{BB95}.

\item[Archivdatei:]
Bei der Verwendung von Archivdateien werden die Informationen f"ur alle Revisionen eines Objektes in einer Datei --- dem {\em Archiv} --- gespeichert. Eine bestimmte Revision wird wiederhergestellt, indem die Datei berechnet wird und nur die f"ur die gew"unschte Revision zutreffenden Modifikationen (z.B. L"oschungen und Einf"ugungen) vorgenommen werden. Dieses Verfahren wird u.a. von SCCS ({\VAS}~\ref{sccs}) und VTML ({\VAS}~\ref{vtml}) verwendet.
\end{description}


Datenmodelle, Unterst"utzung kooperativer Arbeit sowie Speicherverfahren f"ur das Management der Evolution einzelner Ressourcen bilden die Grundlage f"ur die Versionierung komplexer, aus mehreren Ressourcen bestehender Strukturen ({\VKA}~\ref{Kap. kontexte}). 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Anforderungen an Versionierungssysteme im WWW}
\label{verAnf}
In diesem Abschnitt werden Anforderungen an Versionierungssysteme im WWW aufgestellt, nach denen die in Abschnitt~\ref{verLoesungen} vorgstellten Versionierungsans"atze abschlie"send bewertet werden. Die Anforderungen werden unterteilt in funktionale Anforderungen ({\VAS}~\ref{fktVerAnf}) und technische Anforderungen ({\VAS}~\ref{techVerAnf}).

\subsection{Funktionale Anforderungen}
\label{fktVerAnf}
Die im folgenden dargestellten Anforderungen beschreiben  die notwendige Funktionalit"at eines Versionierungssystems im WWW. Wie am Anfang des Kapitels bereits erw"ahnt, haben passive Benutzer und Entwickler unterschiedliche Anforderungen an die Versionierung von Datenbest"anden im WWW. F"ur den passiven Benutzer stehen folgende Anforderungen im Vordergrund:

\begin{description}
\item[Unterst"utzung stabiler, versionierter Hyperlinks:] Es sollte f"ur den Benutzer m"oglich sein, Links zu der initialen, einer spezifischen oder der aktuellen Version einer Ressource zu verfolgen und zu speichern, ohne da"s diese Links nach der Entwicklung einer neuen Version ung"ultig oder falsch werden. 
\item[Visualisierung von Versionstopologien:] Die Metainformationen (z.B. Autor, Datum der letzten "Anderung, etc.) aller existierenden Versionen einer Ressource m"ussen in einem Standardformat von allen Clients genutzt werden k"onnen (z.B. HTML-Text \cite{R*96}), damit sich ein Benutzer "uber die Entwicklung einer Ressource informieren kann und anhand der Metainformationen eine f"ur ihn interessante Version ausw"ahlen kann.
\item[Zugang zu einer auf dem Server definierten Standard-Version:] Wird keine spezielle Version eines Objektes vom Client angefordert, liefert der Server eine Standard-Version (z.B. die aktuellste). Dies ist der einfachste Weg die Kompatibilit"at  mit Clients zu wahren, die keine Versionierung unterst"utzen.
\item[Zugang zu "`verwandten"' Versionen:] "`Verwandte"' Versionen sind z.B. die erste Version eines Dokumentes (Wurzelversion), die vorausgegangene und die nachfolgende Version eines Dokumentes und die Standard-Version. 
\end{description}

Die dar"uber hinausgehenden Anforderungen eines Entwicklers hinsichtlich der Versionierung von Ressourcen im WWW sind:

\begin{description}
\item[Unterst"utzung unsichtbarer Wartung von Ressourcen:] Entwickler von WWW Ressourcen mu"s es m"oglich sein, unsichtbar f"ur den Benutzer einer Ressource neue Versionen dieser Ressource zu erzeugen und sie erst f"ur den Benutzer zugreifbar zu machen, wenn die Bearbeitung abgeschlossen ist, bzw. er die neue Version "offentlich freigibt. Das kann z.B. so erfolgen, da"s ein Entwickler eine bestimmte Version einer Ressource per HTTP in seinen {\brow} l"adt, sie dann lokal editiert und nach Abschlu"s der "Anderungen wieder an den Server sendet, der eine neue Version erzeugt und diese dann "offentlich zug"anglich macht.
\item[Unterst"utzung paralleler asynchroner Entwicklung:] Durch die Speicherung mehrerer Varianten einer Ressource und der sp"ateren Zusammenf"uhrung zu einer gemeinsamen Revision wird das parallele asynchrone Arbeiten mehrerer Entwickler an einer Ressource m"oglich.
\item[Zugangskontrolle zu Ressourcen:] In einigen F"allen ist das parallele asynchrone Bearbeiten einer Ressource nicht erw"unscht. Der Entwickler ben"otigt dann die M"oglichkeit Ressourcen zu sperren. Dies mu"s aber kein Editieren der gesperrten Ressourcen nach sich ziehen, da Ressourcen evtl. nur gesperrt werden sollen, um "Anderungen an diesen zu verhindern und so die Konsistenz mit einer gerade in Bearbeitung befindlichen Ressource zu bewahren.
\end {description}


Je  nach Einsatzzweck des Versionierungssystems mu"s sowohl die vom lesenden Benutzer als auch die vom Entwickler geforderte Funktionalit"at via WWW zug"anglich sein. Es ist z.B. denkbar, da"s die versionierten Ressourcen per WWW nur f"ur den lesenden Benutzer bereitgestellt werden sollen, es aber aufgrund der entstehenden Sicherheitsrisiken keine M"oglichkeit gibt, neue Versionen per WWW Zugriff zu erzeugen. Soll dagegen die weite Verbreitung und einfache Bedienung des WWW f"ur CSCW genutzt werden, mu"s auch die vom Entwickler geforderte Funktionalit"at per WWW Zugriff zur Verf"ugung stehen (vgl. z.B. Abschnitt~\ref{verCGI}).


\subsection{Technische Anforderungen}
\label{techVerAnf}
Versionierungssysteme f"ur den Einsatz im Zusammenhang mit WWW Ressourcen finden eine Reihe von vorgegebenen Rahmenbedingungen (z.B. verschiedene {\brow}, Server, Datenformate, unterschiedliches Anwenderwissen etc.) vor.  Um sich diesen Bedingungen anzupassen, sollten Versionierungssysteme folgende technische Anforderungen erf"ullen:

\begin{description}

\item[Kompatibiltit"at:] Ein Versionierungssystem im WWW ist im Idealfall kompatibel zu vorhandenen {\brow}n und WWW Servern und erlaubt deren Weiterverwendung unabh"angig vom Versionierungssystem.
Das bedeutet u.a., da"s spezifische Versionen via URL addressierbar sein sollten. Dadurch wird es m"oglich, von vorhandenen {\brow}n auf beliebige versionierte Ressourcen zuzugreifen. W"urde hingegen die Versionsinformation in einem neu definierten HTTP {\em request header} ({\VAS}~\ref{http})  "ubergeben, m"u"sten {\brow} und WWW Server erweitert werden, um diesen zu senden bzw. zu verarbeiten.

\item[Flexibilti"at:] Ein Versionierungssystem sollte in der Lage sein, beliebige Typen von vorhandenen Ressourcen zu versionieren und z.B. nicht auf HTML Dateien beschr"ankt sein, da der multimediale Anteil im WWW vorhandener Ressourcen (Bilder, Audio, Video) st"andig zunimmt.

\item[Effizienz:] Es ist w"unschenswert, da"s die zwischen {\brow} und Server "ubertragene Datenmenge zur Abfrage bzw. "Ubertragung von Revisionen m"oglichst klein gehalten wird. So sollte es m"oglich sein, durch Angabe einer Revisionsnummer eine spzifische Version vom Server anzufordern und nicht eine komplette Archivdatei vom Server laden zu m"ussen, aus der der versionierungsf"ahige {\brow} die gew"unschte Version extrahiert. Das Versionierungssystem sollte f"ur effiziente Bennenung, Speicherung  und Retrieval spezifischer Instanzen von Ressourcen sorgen.

\item[Transparenz und Benutzbarkeit:] Ein nur lesend zugreifender Benutzer mu"s von der Implementation des Versionierungssystems keine Kenntnis erlangen. F"ur ihn ist die M"oglichkeit der direkten und einfachen Auswahl verschiedener Versionen von Ressourcen relevant.

\end{description}

Funktionale und technische Anforderungen bilden die Grundlage der Bewertung der im folgenden betrachteten Ans"atze f"ur Versionierungssysteme im WWW.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Technologien}
\label{verLoesungen}
In diesem Abschnitt werden verschiedene Technologien f"ur die Versionierung von Ressourcen im WWW exemplarisch vorgestellt. Zuerst wird in Abschnitt~\ref{verRed} die M"oglichkeit zur Versionierung ohne die Unterst"utzung spezieller Techniken und Werkzeuge dargestellt. Die weiteren betrachteten Technologien setzen auf verschiedenen Ebenen des WWW an ({\VAB}~\ref{verAnsaetze}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/versionierung/verAnsaetze.eps}
\end{center}
\caption{Versionierungsans"atze im WWW}
\label{verAnsaetze}
\end{figure}


VTML ist eine Dokumentenbeschreibungssprache f"ur die Speicherung von Versionsinformationen (2) und kann in HTML und SGML Dokumenten verwendet werden ({\VAS}~\ref{vtml}). Der dritte Ansatz (3) setzt auf die Anbindung eines bereits vorhandenen Versionierungssystems "uber die CGI Schnittstelle eines WWW Servers ({\VAS}~\ref{verCGI}). Eine weitere Basis (4) f"ur die Versionierung von WWW Inhalten bietet die Erweiterung des HTT Protokolls ({\VAS}~\ref{verHTTP}).

\subsection{Versionierung durch redundante Datenhaltung}
\label{verRed}
Die Aufgabe eines Versionierungssystems ist die Bereitstellung eines Zugangs zu s"amtlichen Revisionen und Varianten einer Ressource. Im dateibasierten WWW Zusammenhang bedeutet dies, da"s alle "Anderungen an Ressourcen in eigenen Dateien gespeichert und diese dann eindeutig benannt werden m"ussen, um die eindeutige Referenzierung einer bestimmten Version zu erm"oglichen. Der Zugriff durch den Benutzer erfolgt dann mittels Angabe eines f"ur jede Version unterschiedlichen Dateinamens ({\VAB}~\ref{verAnsaetze}, (1)). Diese Art der Versionierung erfolgt also unabh"angig von {\brow}, WWW Servern und dem HTT Protokoll. 


\subsubsection*{Anwendungsbeispiel}
Ein versioniertes Dokument unterscheidet sich in diesem Fall intern nicht von einem nicht versionierten Dokument, da die Metainformationen "uber den Versionierungsgraphen au"serhalb des Dokumentes gesammelt werden m"ussen. Die verschiedenen Versionen werden nur "uber ihren Dateinamen (z.B. {\em datei\_Ver\_1\_0.html}, bzw. {\em datei\_Ver\_1\_1.html}) einer Versionshistorie zugeordnet. Der Anwender ruft diese Dateien per URL ab. Die Realisierung einer abfragbaren Versionstopologie erfolgt durch die Generierung einer speziellen Datei (z.B. {\em datei\_Ver\_Hist.html}) sobald eine neue Version einer Ressource erstellt wird. Diese Versionshistorie enth"alt Metainformationen "uber die verf"ugbaren Versionen einer Ressource sowie Hyperlinks zu diesen. Setzt man CGI Skripte ein, ist es auch m"oglich, die Versionshistorien zu ihrem Abfragezeitpunkt neu zu berechnen.


\subsubsection*{Bewertung}
Anhand der in Abschnitt~\ref{verAnf} aufgestellten Anforderungen an Versionierung im WWW wird nun die Versionierung durch redundante Datenhaltung bewertet.

\begin{description}
\item[Funktionale Anforderungen:] Die Anforderungen des passiven Benutzers sind durch schematisch benannte versionierte Ressourcen, bzw. Hyperlinks erf"ullbar. Die Anforderungen des Entwicklers erfordern die Programmierung von Skripten, die die n"otige explizite Benennung neuer und die evtl. Umbenennung "alterer Versionen, die Verwaltung von Metainformation (Datum der "Anderung, Bearbeiter, Kommentare, ...) und die Verhinderung von parallelen Schreibzugriffen auf eine Ressource "ubernehmen. Desweiteren ist ein Skript n"otig, das Informationen "uber die Versionstopologie einer Ressource erzeugt und z.B. im HTML Format bereitstellt.
\item[Technische Anforderungen:]  Volle Kompatibilit"at mit existierenden {\brow}n und Servern ist gegeben, da diese nichts von der Existenz eines solchen Versionierungssystems erfahren m"ussen. Der gro"se Vorteil dieses Ansatzes liegt in seiner Flexibilit"at gegen"uber verschiedenen Datenformaten (Texte, Bilder, Audio, Video). Da die Metainformationen getrennt von den versionierten Ressourcen verwaltet werden, spielt deren Datenformat keine Rolle. Die Effizienz ist in Bezug auf die Zugriffsgeschwindigkeit auf Daten optimal, da keine Berechnungen zur Wiederherstellung einer spezifischen Version durchgef"uhrt werden m"ussen. Die Speicherung ist nicht effizient, da nicht nur die Unterschiede von Version zu Version gespeichert werden, sondern ganze Kopien von Dateien. Die Speicherung einer WWW Struktur in mehreren Versionen erfordert so einen hohen Bedarf an Speicherplatz und f"uhrt zu Redundanzen. Transparenz und einfache Benutzbarkeit sind gegeben, da der passive Benutzer nur Dateien mit unterschiedlichen Namen per URL abruft.
\end{description}

Zusammenfassend kann festgestellt werden, da"s, wenn die n"otigen Werkzeuge bereitstehen, die den Entwickler neuer Versionen von Ressourcen von den Verwaltungsaufgaben (z.B. Bennung, Verwaltung der Metainformationen, Sperrung) entlasten, dieser Ansatz volle Flexibilit"at in Bezug auf versionierte Datenformate und verwendete {\brow} und WWW Server bietet. Der Nachteil des gro"sen Speicherplatzverbrauches f"ur die redundante Datenspeicherung ist insbesondere im Zusammenhang mit Bildern und Grafiken sowie Multimediadaten nicht zu untersch"atzen.
 
\subsection{Versionierung durch HTML Erweiterungen}
\label{verHTMLErw}
HTML Erweiterungen f"ur die Integration spezieller Information in HTML Dokumente sind insbesondere im Datenbankbereich ({\VAS}~\ref{msql}) sowie bei der Integration von Skripten ({\VAS}~\ref{dcomWWW}) verbreitet. Es ist m"oglich, mit Hilfe von SGML Kommentaren beliebige Informationen in HTML Dokumente einzubinden und diese dann durch ein Programm auf dem Server oder dem Client auswerten zu lassen. Prinzipiell hat dieses Vorgehen den Nachteil, da"s der Ansatz von einem HTML oder SGML Dokument abh"angig ist und z.B. nicht auf Bilddateien "ubertragen werden kann. Desweiteren m"ussen Client und/oder Server erweitert werden, damit sie die zus"atzlichen Informationen auswerten k"onnen. 

Ein Beispiel f"ur die Einbindung von Versionierungsinformationen in HTML oder SGML Dokumente ist die {\em Versioned Text Markup Language} (VTML).

\subsubsection*{Versioned Text Markup Language}
\label{vtml}
VTML ({\em Versioned Text Markup Language}) ist eine Dokumentenbeschreibungssprache f"ur die Speicherung von Versionsinformationen \cite{VD95}. Das Hauptziel von VTML ist es, die asynchrone Zusammenarbeit mehrerer Autoren bei der Erzeugung und Editierung von Textdokumenten zu erm"oglichen. 

VTML unterst"utzt das Datenmodell des azyklischen Graphen. VTML bietet keine Sperrkonzepte jedoch das Zusammenf"uhren mehrerer Varianten zu einer gemeinsamen Folgerevision ({\em merge}) und unterst"utzt so das asynchrone, parallele Arbeiten an Ressourcen. Mehrere Versionen einer Ressource werden in einer Archivdatei gespeichert und bei Bedarf aus dieser wiederhergestellt. 

\subsubsection*{Beschreibung von VTML}
VTML Daten werden in SGML Kommentaren in einem HTML oder SGML Dokument untergebracht. So k"onnen sie von nicht VTML-f"ahigen Werkzeugen ignoriert werden. Das VTML Schl"usselwort {\em INS } kennzeichnet Einf"ugungen und das Schl"usselwort {\em DEL} L"oschungen. Vor der Visualisierung eines Dokumentes mu"s ein VTML Parser dieses in Abh"angigkeit von der zu visualisierenden Version filtern.

VTML Dokumente werden "ahnlich HTML Dokumenten gekennzeichnet durch
\begin{flushleft}
\label{vtmldok}
$<$!$--$\{VTML {\em Attribute}\}$-->$ VTML Dokument $<$!$--$\{/VTML\}$-->$
\end{flushleft}

Die Attribute beschreiben allgemeine Charakteristika des Dokumentes und m"ussen zumindest den Namen des Dokumentes und die aktuelle Versionsnummer enthalten, die automatisch angezeigt wird, wenn der Benutzer keine Versionsnummer in seiner Anfrage spezifiziert. 

Attributlisten bezeichnen die Attribute, die f"ur mehrere Operationen in einem Dokument G"ultigkeit besitzen. Hierbei sind zumindest der Name des Autors, die Version und das Datum der Modifikation anzugeben. W"ahrend der Editierung sollte die Version als CURRENT, und das Datum als NOW angegeben werden. Die tats"achlichen Werte werden dann w"ahrend des Festsetzens einer neuen Version, dem sogenannten "'check in"' automatisch (z.B. von einem Serverskript) eingesetzt.  Im Beispiel werden zwei Attributlisten benutzt, um nicht bei jeder INS bzw. DEL Operation die ansonsten n"otigen Angaben zu Autor, Versionsnummer und Datum wiederholen zu m"ussen.
 
\begin{flushleft}
$<$!$--$\{ATTR ID=1 vers=1 author="`fabio"' date="`Jul 16, 1996"'\}$-->$ \newline
$<$!$--$\{ATTR ID=2 vers=CURRENT author="`david"' date=NOW\}$-->$ \newline
$<$!$--$\{INS ATTR=1\}$-->$ Dies ist $<$!$--$\{DEL ATTR=2\}$-->$ dein $<$!$--$\{/DEL\}$-->$ $<$!$--$\{INS ATTR=2\}$-->$ mein $<$!$--$\{/INS\}$-->$ Dokument. $<$!$--$\{/INS\}$-->$
\end{flushleft}

INS und DEL Operationen k"onnen beliebig geschachtelt werden. Daten, die mit DEL gekennzeichnet sind, werden w"ahrend der Anzeige ignoriert. Ein VTML Dokument enth"alt also alle Informationen, um den Inhalt jeder Version zu berechnen.

Neben den Attributlisten und der Kennzeichnung der Einf"uge- und L"oschoperationen lassen sich auch mehrere parallel entstandene Varianten einer Version zu einer gemeinsamen neuen Version zusammenfassen. 

Desweiteren ist es m"oglich, Operationen, die ein anderes Dokument betreffen, zu speichern. Dies ist sinnvoll, wenn man keinen direkten Zugang zu dem Dokument hat, da"s man editieren m"ochte. Bei der jetzigen Implementation von VTML m"ussen die extern gespeicherten Modifikationen vor dem anzuzeigenden Dokument den Parser durchlaufen, dessen Algorithmus hier vereinfacht dargestellt wird (aus: \cite{VD95}):

\begin{xple}
\label{vtmlParser}
doPrint(content)
char *content
/* SIMPLIFIED */
\{
  if ((type == INS) $\mid \mid$ (type == MERGE))
     if (in\_chain (version, verstbd))
           printf("'\%s"', content) ;
  else
     if ((!in\_chain (version, verstbd)) \&\&
        (in\_chain (lastins, verstbd)))
           printf("'\%s"', content) ;
\}
\end{xple}
W"ahrend der grammatischen Analyse durch den Parser wird ein Stapel von Versionen erzeugt. Immer wenn ein neuer VTML Bezeichner wie z.B. INS oder DEL gefunden wird, wird dieser auf den Stapel gelegt und der Textinhalt untersucht. Handelt es sich bei dem Typ des Bezeichners um INS oder MERGE, wird gepr"uft, ob die Version des Bezeichners ({\em version}) ein Vorfahre der anzuzeigenden Version ({\em verstbd}) ist. Ist dies der Fall, wird der Inhalt angezeigt. Handelt es sich um ein DEL, wird gepr"uft, ob die Version des Bezeichners kein Vorfahre ist (und daher in der anzuzeigenden Version zu l"oschen ist) und ob die Version des Textes in die das DEL eingef"ugt wurde ein Vorfahre des anzuzeigenden Textes ist. Ist dies der Fall, wird der Inhalt angezeigt. Die Vereinfachung des obigen Verfahrens besteht in der Ausklammerung der rekursiven Aufrufe, die n"otig sind um verschachtelte Operationen, die in {\em content} vorhanden sein k"onnten zu behandeln.

\subsubsection*{Anwendungsbeispiel}
Die Autoren schlagen zwei verschiedene Anwendungsm"oglichkeiten vor. Zum einen k"onnte ein WWW {\brow} um Bearbeitungsf"ahigkeiten erweitert werden, der dann auf dem Client\-rech\-ner neue Versionen von VTML Dokumenten erzeugen w"urde und diese zum Server sendet und dort ablegt. Der Client w"urde also eine komplette VTML Datei laden, sie lokal editieren und wieder zum Server schicken.\footnote{ Die Autoren "au"sern sich in ihrem Artikel nicht zu den bei gleichzeitiger Editierung eines Dokumentes entstehenden Konflikten, wenn diese neuen Versionen auf dem Server abgelegt werden. Dort m"u"ste zumindest ein Serverskript aktiv sein, das Schreibkonflikte behandelt oder das das gleichzeitige Editieren von VTML Dateien durch mehrere Bearbeiter verhindert.}

Die andere Anwendungsm"oglichkeit von VTML ist ein Serverskript. Es k"onnte ein neuer Inhaltstyp ({\em content-type}) von HTTP Nachrichten f"ur VTML definiert werden, der dann mittels HTTP zwischen {\brow} und Server verhandelt wird. Wenn ein nicht VTML-f"ahiger {\brow} eine VTML Datei unter dem URL "`http://my.host/dir/file.vtml"' anfordert, berechnet der Server die aktuelle Version des Dokumentes und schickt sie als HTML Datei dem Client. Fordert der Client eine spezifische Version unter dem URL "`http://my.host/dir/file.vtml/1.3"' an, generiert das Serverskript die entsprechende Version und liefert sie an den Client aus.

\subsubsection*{Bewertung}
Anhand der Anforderungen an Versionierung im WWW aus Abschnitt~\ref{verAnf} wird nun die Eignung von HTML Erweiterungen am Beispiel von VTML als Ansatz f"ur Versionierung im WWW bewertet.

\begin{description}
\item[Funktionale Anforderungen:] Die funktionalen Anforderungen des lesenden Benutzers lassen sich  z.B. durch eine Implementation von VTML als Serverskript erf"ullen. Die Addressierung w"urde in der oben beschriebenen Art und Weise erfolgen und entweder die aktuelle oder eine spezifische Version liefern. Das Skript m"u"ste desweiteren in die Lage versetzt werden, aus den in einer VTML Datei enthaltenen Metainformationen eine Versionshistorie in Form einer HTML Datei zu erzeugen, die die einzelnen Versionen einer Ressource mit ihren Metadaten zugreifbar macht. Sollen Anwender per WWW neue Versionen eines VTML Dokumentes erzeugen k"onnen, m"u"ste entweder der Client wie oben beschrieben erweitert werden oder das Serverskript mu"s in die Lage versetzt werden, eine vom Client zum Server "ubertragene neue Version in ein vorhandenes VTML Dokument einzuf"ugen und dabei evtl. auftretende Konflikte zu behandeln.

\item[Technische Anforderungen:] Beschr"ankt sich der Benutzer im WWW auf den lesenden Zugriff, k"onnen um Versionierungsinformationen erweiterte HTML Dateien von jedem {\brow} gelesen werden. Eine Servererweiterung ist in jedem Fall notwendig, um das Wiederherstellen spezifischer Versionen von Dateien aus den Archivdateien zu erm"oglichen. Generell sind Systeme wie VTML auf HTML/SGML Dokumente beschr"ankt und lassen sich nicht auf Bilder oder Datenstr"ome wie Audio und Video "ubertragen. Transparenz und Benutzbarkeit ist bei oben beschriebener Adressierung versionierter Daten f"ur den lesenden Benutzer gegeben. F"ur den Entwickler ist die Unterst"utzung durch Werkzeuge unabdingbar, da es ihm nicht zuzumuten ist, per Hand VTML Schl"usselworte in ein Dokument einzuf"ugen.
\end{description}

Ans"atze wie VTML haben gegen"uber der Versionierung durch redundante Datenhaltung den Vorteil, da"s sie die Versionsinformation in dem versionierten Dokument speichern. So lassen sich mehrere Versionen in einem Dokument ablegen, Speicherplatz wird effizient genutzt und es treten keine Redundanzen auf. Die gr"o"ste Einschr"ankung des Ansatzes ist die Beschr"ankung auf HTML/SGML Dateien. Die vom Speicherplatzbedarf wesentlich anspruchsvolleren Datenformate f"ur Bilder, Audio und Video lassen sich mit diesem Ansatz nicht versionieren.

\subsection{Versionierung durch Anbindung bestehender Systeme}
\label{verCGI}
Die Anbindung bereits bestehender Versionierungssysteme wie z.B. RCS oder SCCS an das WWW erfolgt in der Regel "uber die CGI Schnittstelle des WWW Servers oder eine Erweiterung der Serversoftware. Funktionalit"at und Flexibilit"at h"angen dann prinzipiell nur von dieser Versionierungssoftware ab. In der Praxis m"ussen WWW Schnittstellen f"ur die ben"otigten Funktionalit"aten geschaffen werden.

Das WWRC (s.u.) ist ein Versionierungssystem f"ur die Unterst"utzung kooperativer Arbeit mehrerer Entwickler an einem Softwareprojekt und wird durch HTML Formulare und CGI Skripte realisiert, die ein vom WWW unabh"angiges Versionierungssystem nutzen. Bei der Servererweiterung in Abschnitt~\ref{serverErw} wird dagegen nur die vom lesenden Benutzer ben"otigte Funktionalit"at unterst"utzt und der Zugriff auf versionierte Ressourcen erfolgt "uber erweiterte URLs.

\subsection*{WWRC}
Das WWRC (World Wide Revision Control) System dient der Versionierung von Quell\-code\-da\-teien bei der Softwareentwicklung \cite{R*96}. Es erm"oglicht die Benutzung des Versionierungssystems RCE --- eine Weiterentwicklung von RCS \cite{BB95} --- "uber beliebige WWW {\brow} ohne da"s dem Entwickler direkter Zugang zu den verwalteten Dateien gegeben werden mu"s. Dies ist insbesondere in Unternehmen bei kurzzeitig eingestellten freien Mitarbeitern oder Heimarbeitern von Vorteil, da diese keine Benutzerrechte auf dem Rechner des Versionierungssystems bekommen m"ussen und dadurch das Sicherheitsrisiko des von au"sen w"ahlbaren Zugangs zum Dateisystem vermieden wird.

Es handelt sich hierbei nicht um ein allgemeines Versionierungssystem f"ur das WWW sondern um ein System zur verteilten Bearbeitung von Quellcodedateien. So ist es z.B. nicht m"oglich, ohne eine Hilfsanwendung spezifische Versionen anhand eines URL anzufordern. Bei diesem Ansatz werden jedoch die Vorteile und Probleme einer Clienterweiterung f"ur das verteilte asynchrone Bearbeiten von Dokumenten deutlich.
 
\subsubsection*{Aufbau des WWRC}
Das WWRC System setzt sich aus folgenden Komponenten zusammen ({\VAB}~\ref{verCgi1}):
\begin{description}
\item[RCE:] Die Revision Control Engine (RCE) bietet eine Anwendungsprogrammierschnittstelle (API), die die Funktionalit"at der RCE von au"sen zug"anglich macht.
\item[CGI Anwendung:] Die CGI Anwendung "ubernimmt die Kommunikation zwischen WWW Server und der RCE.
\item[WWW Client und Server:] Dies k"onnen beliebige WWW {\brow} (z.B. {\mos}, {\nav}, {\ie}, etc.) und WWW Server (z.B. {\apa}, {\jig}, etc.) sein. 
\item[Hilfsanwendung\footnote{Eine Hilfsanwendung reagiert wie ein {\plugin} auf den Inhaltstyp einer HTTP Nachricht und wird dann automatisch vom {\brow} gestartet. Allerdings findet die Bearbeitung durch die Hilfsanwendung in einem zu dem {\brow} separatem Proze"s statt, w"ahrend ein {\plugin} die F"ahigkeiten des {\brow}s erweitert und die Bearbeitung innerhalb des {\brow} Prozesses stattfindet.} beim Client :] Die Hilfsanwendung auf der Seite des Client erm"oglicht die "Ubertragung gro"ser Dateien sowohl vom als auch zum Server, sowie deren korrekte Visualisierung auf dem Client Rechner.
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=4cm
\epsffile{Bilder/versionierung/verCgi1.epsf}
\end{center}
\caption{Komponenten des WWRC}
\label{verCgi1}
\end{figure}

\subsubsection*{Funktionsweise} 
Der Benutzer macht s"amtliche Eingaben f"ur das System "uber die Schnittstelle seines {\brow}s in dem er Formulare ausf"ullt. Mit der Hilfe von Formularen ist es m"oglich, notwendige Kontextinformationen "uber eine erweiterte URL an das CGI Programm weiterzugeben und so eine verbindungsorientierte Kommunikation zwischen Client und Server zu simulieren ({\VAS}~\ref{cgi}). 

Die Arbeitssitzung eines Benutzers des WWRC Systems besteht aus folgenden Schritten: 

\begin{description}
\item[Anmeldung:] Bevor ein Benutzer mit dem WWRC System arbeiten kann, mu"s er sich bei diesem mit Benutzernamen und Passwort anmelden. 
\item[Archivdatei ausw"ahlen:] Nach der erfolgreichen Anmeldung hat der Anwender u.a. die M"oglichkeit eine Archivdatei auszuw"ahlen, in der die verschiedenen Versionen einer Ressource enthalten sind.Der Versionierungsgraph einer Archivdatei wird bei Bedarf als formatierter Text visualisiert, wobei sich  der besseren "Ubersicht wegen Subgraphen aus- und wieder einblenden lassen. 
\item[Spezifische Version ausw"ahlen:] Wird eine Revision oder Variante ausgew"ahlt, erh"alt der Anwender mehr Informationen dar"uber wie z.B. Erstellungsdatum, Autor, den aktuellen Zustand und Kommentare.
\item[Daten"ubertragung zum Client:] Ist eine Version ausgew"ahlt, ist es m"oglich diese zur Bearbeitung aus der Versionskontrolle herauszunehmen (engl. {\em checkout}) und zum Rechner des Anwenders zu "ubertragen. Im ersten Schritt einer Anfrage f"ur ein {\em checkout}, f"uhrt der Server ein lokales {\em checkout} durch, indem er die Datei in einem f"ur jeden Benutzer spezifischen Verzeichnis ablegt. Der Antwort des Servers setzt sich u.a. aus dem Dateinamen, der Verzeichnisposition, dem speziellen Typ "'rceco"' und der Datei selbst zusammen. Der spezielle Typ der Datei f"uhrt dazu, da"s der {\brow} des Client die o.g. Hilfsanwendung ausf"uhrt. Die Hilfsanwendung liest den Antwortkopf des Servers, bestimmt so Name und Verzeichnis der neu zu erzeugenden Datei und legt den Inhalt der Datei dort ab. Danach wird eine Empfangsbest"atigung an den Server gesendet, woraufhin dieser die lokale Kopie der Datei zur L"oschung freigibt. War die Daten\-"uber\-tra\-gung nicht erfolgreich, ist es f"ur den Benutzer noch immer m"oglich, die Datei noch einmal anzufordern, ohne da"s evtl. zwischenzeitlich entstandene "Anderungen die zu "ubertragende Datei beeinflussen.
\item[Bearbeitung:] Die Bearbeitung der Datei erfolgt lokal auf dem Rechner des Client.
\item[Daten"ubertragung zum Server:] Um eine Datei wieder unter die Versionskontrolle des WWRC zu stellen (engl. {\em checkin}), schickt der Server eine Datei an den Client, in welcher die von der Hilfsanwendung zu "ubertragende Datei bestimmt wird. Die Hilfsanwendung wertet diese Angaben (Dateiname, Verzeichnisangabe) aus, liest die entsprechende Datei ein und baut eine direkte Verbindung zum Server auf, der die Datei in einem speziellen Verzeichnis ablegt. Aus diesem Verzeichnis des Servers findet dann das {\em checkin} in die zugeh"orige Archivdatei statt.
\end{description}

Abbildung~\ref{vercgi2} visualisiert die w"ahrend des {\em checkout} ablaufenden Prozesse.  


\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=8cm
\epsffile{Bilder/versionierung/verCgi2.epsf}
\end{center}
\caption{Prozesse w"ahrend des {\em checkout}}
\label{vercgi2}
\end{figure}


\subsubsection*{Bewertung}
Das WWRC ist auf die Versionierung von Programmcode zugeschnitten und erhebt nicht den Anspruch ein allgemeines Versionierungssystem f"ur das WWW zu sein, daher kann die Bewertung nicht nach den in Abschnitt~\ref{verAnf} erarbeiteten Kriterien erfolgen. Stattdessen soll hier allgemein die Nutzung von Clienterweiterungen zur Versionierung von Ressourcen am Beispiel des WWRC bewertet werden.

Die Clienterweiterung im WWRC System ist lediglich f"ur den Entwickler neuer Versionen notwendig. Geht es nur darum, versionierte Daten abzufragen und zu visualisieren, reicht das Mittel der erweiterten Adressierung versionierter Ressourcen wie in Abschnitt~\ref{verHTMLErw} vorgestellt aus.

Eine plattformabh"angige Clienterweiterung schr"ankt ihre Einsatzf"ahigkeit im WWW ein. Unabh"angiger w"are die Realisierung als {\java} Applet. Hier ergibt sich jedoch das Problem der Sicherheitseinschr"ankungen von Applets, die nicht auf die Festplatte eines Clientrechners zugreifen d"urfen. Ein {\plugin} als {\java} Anwendung setzt das Vorhandensein eines {\java} Interpreters voraus, entlastet aber zumindest von der Notwendigkeit verschiedenen Code f"ur die unterschiedlichen Plattformen ausliefern zu m"ussen. 

Vorteile bietet das WWRC bei der Unterst"utzung von Versionskontrolle und kooperativer Arbeit dadurch, da"s es verteilte Versionskontrolle erm"oglicht, ohne da"s die Entwickler direkten Rechnerzugang zu den Archivdateien haben m"ussen. Ein weiterer Vorteil ist die Nutzung des WWW als Basis f"ur computerunterst"utzte kooperative Arbeit (CSCW), da der Zugang zum System so nahezu von jedem Rechner aus m"oglich ist.

\subsection{Erweiterungen von HTTP}
\label{verHTTP}
 In diesem Abschnitt werden zwei Vorschl"age f"ur Erweiterungen des HTT Protokolls vorgestellt und abschlie"send kritisch betrachtet. W"ahrend der Vorschlag von \cite{W96} ausschlie"slich auf die Versionierungsunterst"utzung f"ur das WWW zielt, beschreiben \cite{CF96} in ihrem Vorschlag ein Protokoll f"ur das verteilte Verfassen und Versionieren von Dokumenten, von dem in diesem Zusammenhang aber nur die die Versionierung betreffenden Abschnitte erl"autert werden.

\subsubsection*{Protokoll f"ur das verteilte Verfassen und Versionieren von Dokumenten}
\label{davp}
Die HTTP Erweiterung nach \cite{CF96} setzt sich aus der Beschreibung der funktionalen Definition, der Syntax der HTTP Anfrage, sowie der Reaktion des Servers auf die Anfrage f"ur u.a. folgende neue HTTP Methoden zusammen:
\begin{description}
\item[CHECKOUT] fordert eine Ressource vom Server an, "ubertr"agt sie zum Client und kann die Datei bei Bedarf f"ur andere Benutzer sperren. Als Attribute m"ussen angegeben werden, ob die Datei gesperrt werden soll und welche Version der Ressource von der Methode betroffen ist.
\item[CHECKIN] "ubertr"agt eine Ressource zum Server. Attribute sind: die Version der zu "uber\-tra\-genden Ressource, der Status (aufheben oder bestehen lassen) der Sperrung der Ressource sowie Kommentare des Bearbeiters zu dieser Version.
\item[UNLOCK] enfernt eine Sperre einer Ressource. Attribut ist die spezifische Version der Ressource.
\item[LOCK] sperrt eine Ressource f"ur andere Benutzer. Attribut ist die spezifische Version der Ressource.
\item[DEFAULT] definiert eine spezifische Version einer Ressource als die Standardversion der Ressource, die z.B. als Antwort auf eine GET Anfrage eines Client "ubertragen wird. Attribut ist die spezifische Version der Ressource.
\item[REVLOG] fordert Metadaten (z.B. Versionshistorie, Aufzeichnungen "uber CHECKOUT und CHECKIN Operationen, etc.) "uber Versionierungsinformationen einer Ressource an. Ein Attribut gibt an, ob Metadaten zu einer spezifischen Version, zu allen Versionen oder nur zu einem bestimmten Zweig einer Versionshistorie angefordert werden.
\item[LABEL] weist einer Version einer Ressource einen Textbezeichner zu. Attribute sind hier die spezifische Version sowie der Textbezeichner.
\end{description}

Das Attribut {\em Content-Version} referenziert die von den Methoden eventuell zu spezifizierende Version der Ressource. Die andere M"oglichkeit eine Version in einer Anfrage zu spezifizieren ist das Attribut {\em Content-Label}. Dieses erh"alt als Wert einen zuvor mit der Methode LABEL zugewiesenen Textbezeichner. Die Methode LABEL erm"oglicht dem Entwickler das Erzeugen von Kontexten ({\VKA}~\ref{Kap. kontexte}) indem spezifischen Versionen mehrerer Ressourcen derselbe Bezeichner zugewiesen wird. Beim sp"ateren Retrieval der Ressourcen --- z.B. durch GET oder HEAD ({\VAS}~\ref{http}) --- gibt der Client anstatt einer spezifischen Version den Kontext in Form des Attributes {\em Content-Label} an und der Server ermittelt anhand dessen die spezifische Version der auszuliefernden Ressource.

\subsubsection*{WWW Versionierungsunterst"utzung}
\label{wwwvsup}
W"ahrend in der HTTP Erweiterung nach \cite{CF96} die Spezifizierung einer Version "uber die Attribute der neuen HTTP Methoden erfolgt, wird bei dem Vorschlag von \cite{W96} ein URL versioniert, indem ein Parameter an den URL angeh"angt wird. So w"urde z.B. die Version 3.0 einer Ressource {\em .../foo.html} als {\em .../foo.html;v=3.0} referenziert werden. 

Mit der Methode FLAG k"onnen verschiedene Kennungen (Flags) f"ur Ressourcen gesetzt, gel"oscht und abgefragt werden.  Es gibt EDIT und LOCK Flags. Die FLAG Methode f"uhrt als Gegenstand der Anfrage (engl. {\em request entity body}, {\VAS}~\ref{httpGrundlagen}) immer eine Liste aller f"ur diese Ressource aktiven Kennungen mit sich. Die Liste enth"alt Paare von Benutzerkennungen und die f"ur den jeweiligen Benutzer gesetzten EDIT bzw. LOCK Flags. Die EDIT Kennung hat die Funktion anzuzeigen, da"s eine Ressource gerade von dem genannten Benutzer bearbeitet wird und erm"oglicht dadurch einen Versionierungsstil, der das gleichzeitige Editieren von Dokumenten durch mehrere Benutzer im Sinne von CSCW erlaubt. Das erfordert jedoch ein nachtr"agliches Zusammenf"uhren (engl. {\em merging}) von parallel entstandenen Version. Die LOCK Kennung wird von der unten vorgestellten HTTP Methode LOCK gesetzt, verbietet gleichzeitiges Editieren einer Ressource durch mehrere Benutzer und markiert diese als gesperrt. Die weiteren Methoden sind folgende:
\begin{description} 
\item[LOCK] sperrt den Zugriff auf einen URL mittels der HTTP PUT Methode  ({\VAS}~\ref{httpMethoden}), f"ur alle Benutzer au"ser den Inhaber der die Sperre beantragt hat. Ist in dem URL eine spezifische Version angegeben, gilt die Sperre nur f"ur diese Version, ansonsten werden alle Versionen der Ressource gesperrt. 
\item[UNLOCK] hebt eine bestehende Sperre auf und l"oscht das LOCK Flag des betreffenden Ressource URL.
\item[USE] entspricht der o.g. Methode DEFAULT und definiert eine spezifische Version einer Ressource als die Standardversion der Ressource, die z.B. immer dann als Antwort auf eine GET Anfrage "ubertragen werden soll, wenn die Version der Ressource nicht explizit spezifiziert ist.
\end{description}

Die Versionierung aus mehreren Elementen bestehender Strukturen ({\VKA}~\ref{Kap. kontexte}) kann durch die Verwendung von Konfigurationsdateien erreicht werden. Eine Konfigurationsdatei enth"alt eine Liste von URL Paaren bei denen jeweils ein URL ohne Versionsinformation einem URL mit Versionsinformation zugeordnet ist. So k"onnte z.B. der URL {\em http://www.foo.bar/entry.html} dem versionierten URL {\em http://www.foo.bar/entry.html;v=3.0} zugeordnet sein. Die Konfigurationsdatei wird in den {\brow} des Client geladen und wirkt fortan als Filter, der nicht versionierte URLs automatisch durch versionierte ersetzt.  

\subsubsection*{Bewertung}
Im folgenden wird der Ansatz der Versionierung durch HTTP Erweiterungen im Hinblick auf die in Abschnitt~\ref{verAnf} aufgestellten Anforderungen kritisch betrachtet.

\begin{description}
\item[Funktionale Anforderungen:] Die Funktionalen Anforderungen sind durch die Definition neuer HTTP Methoden und Attribute erf"ullbar. Die Implementation erfordert jedoch die Entwicklung neuer {\brow} die diese Methoden senden k"onnen und neue Server die die entsprechenden Funktionen bereitstellen.
\item[Technische Anforderungen:] Die Kompatibilit"at mit bestehenden {\brow}n und Servern ist nicht gegeben. Flexibilit"at und Effizienz liegen in der Hand des Herstellers des Serversoftware. Der Ansatz gibt hier keinerlei Einschr"ankungen vor. Transparenz und einfache Benutzbarkeit h"angen von der Benutzerschnittstelle der neu zu entwickelnden {\brow} ab.
\end{description}


Beide Ans"atze bieten die Versionierung aus mehreren Elementen bestehender Strukturen --- sogenannter {\em Kontexte} ({\VKA}~\ref{Kap. kontexte}). Im ersten Ansatz ist die Verantwortung daf"ur zwischen Client und Server aufgeteilt. Der Client gibt den gew"unschten Kontext in seiner Anfrage an und der Server versucht anhand dessen die entsprechende Version der Ressource zu bestimmen. Im zweiten Fall entstehen Kontexte durch Konfigurationsdateien, die Hyperlinks dem Kontext entsprechend versionieren. Der Server kennt also nur versionierte Ressourcen jedoch keine Kontexte (da ja die Konfigurationsdateien selbst wieder Ressourcen sind). F"ur diese L"osung ist eine Erweiterung der {\brow} notwendig, die die Konfigurationsdateien lesen und verwalten m"ussen.

HTTP Erweiterungen erm"oglichen die flexibelste und weitgehendste Unterst"utzung von Versionierungskonzepten und erfordern andererseits den gr"o"sten Aufwand zu ihrer Realisierung, da neben dem Protokoll selbst sowohl Client als auch Server erweitert werden m"ussen.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Erweiterung eines WWW Servers}
\label{serverErw}

Im folgenden wird die vom Autor prototypisch implementierte Anbindung des {\em Source Code Control Systems} (SCCS) an den WWW Server {\jig} des WWW Konsortiums vorgestellt. Das Ziel der Anbindung war die praktische Umsetzung der Anforderungen des passiven Nutzers versionierter Information. Es sollten dabei vorhandene Dienste exemplarisch an einen WWW Server angebunden werden.

Das Umfeld der Servererweiterung und die beteiligten Komponenten sind in Abbildung~\ref{sccsJig} dargestellt. Der Client fordert mittels HTTP eine Ressource vom WWW Server {\jig} an. Dieser bestimmt anhand der URI der Anfrage, ob es sich hierbei um eine versionierte Ressource handelt. Ist das der Fall, werden entsprechende SCCS Befehle ausgef"uhrt, die die entsprechende Version aus dem Dateisystem extrahieren. Diese wird dann per HTTP an den Client "ubertragen. Handelt es sich nicht um eine versionierte Ressource, kommuniziert der Server direkt mit dem Dateisystem.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/versionierung/sccsJig.eps}
\end{center}
\caption{Bereitstellung versionierter Textdaten f"ur das WWW}
\label{sccsJig}
\end{figure}

Nach einer kurzen Einf"uhrung in SCCS ({\VAS}~\ref{sccs}), wird Architektur und Funktionsweise des in Java implementierten {\oo}en WWW Servers {\jig} erl"autert ({\VAS}~\ref{jigsaw}). Die Verbindung beider Systeme wird in Abschnitt~\ref{versionImpl} beschrieben.

\subsection{SCCS}
\label{sccs}
Das Source Code Control System (SCCS) ist ein Versionierungssystem, da"s das Datenmodell des azyklischen Graphen verwendet und sowohl Revisionen, Varianten als auch das Zusammenf"uhren mehrerer Versionen unterst"utzt ({\VAS}~\ref{verGrundlagen}). Die verschiedenen Versionen einer Ressource werden in einer Archivdatei gespeichert und bei Bedarf wiederhergestellt. Wird z.B. eine neue Ressource {\em foo.html} unter die Kontrolle von SCCS gestellt, legt SCCS im Verzeichnis der Ressource ein Unterverzeichnis {\em SCCS} an --- sofern dies noch nicht existiert --- und erzeugt in diesem Unterverzeichnis eine {\em Archivdatei} mit dem Prefix {\em s.} namens {\em s.foo.html}. In dieser Archivdatei werden alle Versionen der Ressource inklusive der Metadaten wie "Anderungsdatum, Bearbeiter, Kommentare, etc. gespeichert. Die Ursprungsdatei {\em foo.html} enth"alt zu jedem Zeitpunkt die aktuellste Version der Ressource.

SCCS verf"ugt nicht "uber eine Anwendungsprogrammierschnittstelle (API), daher m"ussen andere Systeme oder Werkzeuge die SCCS Funktionalit"at "uber die im Folgenden vorgestellten Befehlszeilen nutzen.

\subsubsection*{Befehlszeilen}
\label{sccsBefehlszeilen}
SCCS akzeptiert Befehlszeilen im klassischen UNIX Format \cite{BB95}. Eine Befehlszeile besteht aus einem Befehlsnamen, optionalen Parametern und einem oder mehreren Dateinamen. Ein optionaler Parameter beginnt mit einem Bindestrich, dieser unterscheidet ihn von einem Dateinamen. Danach folgt ein einzelner Buchstabe, der die Option identifiziert, und in einigen F"allen eine Zeichenfolge, die als Wert f"ur die Option dient. Die Befehlszeile 

\begin{xple}
prt --s foo.html
\end{xple}

sorgt daf"ur, da"s auf der Standardausgabe Metainformationen (z.B. die Versionsnummer, das Datum der letzten "Anderung, der Benutzername des Bearbeiters dieser Version, etc.) "uber s"amtliche Versionen der Datei  {\em foo.html} ausgegeben werden. Die Option {\em --s} f"uhrt zur Unterdr"uckung der Kommentarinformationen in der Ausgabe. Die Antwort des SCCS Systems auf die obige Befehlszeile ist folgende:
\begin{xple}
SCCS/s.foo.html:

D 1.2.1.1	97/04/21 15:15:20 boesch	5 2	00000/00000/00023

D 1.4	97/04/21 14:50:24 boesch	4 3	00000/00000/00023

D 1.3	97/04/21 14:42:31 boesch	3 2	00000/00000/00023

D 1.2	97/04/21 14:35:27 boesch	2 1	00000/00000/00023

D 1.1	97/04/21 14:33:34 boesch	1 0	00023/00000/00000

\end{xple}

Die Anbindung des WWW Servers {\jig} an SCCS erfolgt "uber Aufrufe von Befehlszeilen und der Auswertung von deren Ausgabedaten.

\subsection{{\jig}}
\label{jigsaw}
{\jig} ist ein in Java ({\VAS}~\ref{java}) geschriebener {\oo}er WWW Server des WWW Konsortiums. Er profitiert von der Plattformunabh"angigkeit jeder in Java geschriebenen Software und ist ohne "Anderungen auf allen Plattformen, auf denen ein Java Bytecode Interpreter zur Verf"ugung steht, lauff"ahig \cite{Kl96}. 

Der Kern von {\jig} ist seine optimierte interne Datenrepr"asentation. Der Server betrachtet jedes Objekt, das er ausliefern kann, z.B. eine Datei oder ein Verzeichnis, als eine {\em Ressource}. Zu jeder Ressource geh"oren Metainformationen wie Datentyp, Datum der letzten "Anderung, Verfallsdatum, Zugriffsschutz, etc. Alle Ressourcen sind persistente Objekte und werden in einem Cache gehalten. Wird eine Ressource wiederholt abgefragt, kann {\jig} diese Anfragen aus seinem Cache bedienen und mu"s bei ausreichendem Hauptspeicher keine Festplattenzugriffe durchf"uhren. {\jig} definiert eine Reihe von Klassen, die verschiedenste Ressourcen implementieren. So ist z.B. die Klasse {\em w3c.jigsaw.resources.Resource} die Oberklasse, aller vom Server ausgelieferten Objekte. Subklassen dieser Klasse sind z.B. {\em w3c.jigsaw.resource.FileResource}, die Dateien auf Ressourcen abbildet und {\em w3c.jig\-saw.re\-source.DirectoryResource} die Verzeichnisse auf Ressourcen abbildet. Eintr"age innerhalb einer Verzeichnisressource sind nicht beschr"ankt auf Dateien oder weitere Verzeichnisse sondern k"onnen beliebige Subklassen von {\em w3c.jigsaw.resources.Resource} sein. Es ist m"oglich Ressourcen zu erzeugen, die keine Entsprechung im Dateisystem haben. So beantwortet eine Instanz der Klasse {\em w3c.jigsaw.resources.RelocateResource} eine HTTP GET Anfrage ({\VAS}~\ref{http}), indem sie den WWW Client dazu auffordert, die gew"unschten Daten unter einem anderen URL zu suchen. 

Alle Ressourcen sind durch den Server konfigurierbar. Dies geschieht mit Hilfe von HTML Formularen zu den einzelnen Ressourcen. So lassen sich z.B. bei einem Dokument {\em Overview.html} HTTP Attribute wie Sprache ({\em Content-Language}), Verfallsdatum ({\em Expires}), Typ des Inhaltes ({\em Content-Type}), etc. "andern. "Anderungen an Ressourcen wirken sich zun"achst nur auf den Cache des Servers im Hauptspeicher aus und werden erst sp"ater abh"angig von Anzahl und Gr"o"se der "ubrigen Ressourcen auf die Festplatte ausgelagert. 

F"ur die Wahl von {\jig} als WWW Server war die dynamische Erweiterbarkeit von Java Anwendungen ausschlaggebend. Es ist f"ur den Administrator eines {\jig} Servers m"oglich, eigene Java Klassen zur Laufzeit in den Server einzubinden. Dies geschieht z.B. indem man sogenannte Verzeichnisschablonen definiert. Verzeichnisschablonen beschreiben, wie Verzeichnisse mit einem bestimmten Namen auf Ressourceninstanzen abgebildet werden. Dabei wird der Name eines Verzeichnisses einer {\java} Klasse zugeordnet. Enth"alt ein vom Client angefragter URL diesen Verzeichnisnamen "ubernimmt die zugeordnete {\java} Klasse die weitere Bearbeitung der Anfrage. Die im Folgenden dargestellte Implementierung basiert auf diesem Konzept und gibt ein Anwendungsbeispiel einer Verzeichnisschablone.

\subsection{Implementierung}
\label{versionImpl}
Die Implementierung der Erweiterung des WWW Servers {\jig} erfolgt in zwei Schritten:

\begin{description}
\item [1. Aufbau von SCCS Datenstrukturen:] Aus dem Aufruf von SCCS Befehlszeilen und deren Auswertung werden Instanzen von {\java} Klassen erzeugt, die den Zustand eines SCCS Verzeichnisses, einer SCCS Archivdatei und einer einzelnen Version aus einer Archivdatei abbilden.
\item [2. Erzeugung von {\jig} Ressourcen:] Alle Objekte, die {\jig} ausliefert, sind Ressourcen ({\VAS}~\ref{jigsaw}). Auf Basis der SCCS Datenstrukturen werden {\jig} Ressourcen erzeugt.
\end{description}

Abbildung~\ref{implKonzept} stellt das Zusammenspiel von SCCS und {\jig} dar. Der Server erh"alt eine HTTP Anfrage und gibt diese an die zust"andige Ressourceklasse weiter. Diese sendet ihrerseits eine Anfrage nach geeigneten SCCS Datenstrukturen an die Abstraktion des SCCS Systems. Die SCCS Klassen rufen SCCS Befehle auf und erzeugen aus der Antwort des SCCS geeignete {\java} Datenstrukturen, aus  denen die zust"andigen Ressourceklassen HTTP Antworten generieren, die der Server an den Client weiterleitet.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/versionierung/implKonzept.eps}
\end{center}
\caption{Zusammenspiel von SCCS und {\jig}}
\label{implKonzept}
\end{figure}

Die Erweiterung des WWW Servers {\jig} erfolgt "uber die Einbindung von {\java} Klassen in den Server.
Steht eine Datei unter der Kontrolle von SCCS, befindet sich im Verzeichnis der Datei ein Unterverzeichnis, da"s die Versionierungsinformationen enth"alt. Diese Tatsache wird bei der Implementierung genutzt, indem der WWW Server {\jig} mittels einer neu definierten Verzeichnisschablone ({\VAS}~\ref{jigsaw}) so konfiguriert wird, da"s er die Bearbeitung von Anfragen, die in der URI der Anfrage die Zeichenkette "'SCCS"' enthalten einer eigens daf"ur angelegten {\java} Klasse "ubertr"agt. Die Einbindung der entsprechenden Klasse in den Server erfolgt "uber ein HTML Formular, das vom Server bereitgestellt wird ({\VAB}~\ref{jigDirTemp}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/versionierung/jigDirTemp.ps}
\end{center}
\caption{Einbindung neuer {\java} Klassen in {\jig}}
\label{jigDirTemp}
\end{figure}

Der Kontext der neu in den Server integrierten Klasse {\em ab.jigsaw.sccs.SccsDirectoryRessource} ist aus einem vereinfacht dargestelltem Ausschnitt der Klassenhierarchie des Servers ersichtlich ({\VAB}~\ref{classKontext}). Jedes vom Server ausgelieferte Objekt ist eine Ressource ({\VAS}~\ref{jigsaw}) und daher eine Instanz der Klasse {\em w3c.jigsaw.resources.Resource} oder einer ihrer Subklassen wie z.B. {\em w3c.jigsaw.resources.DirectoryResource}, die wiederum Superklasse der Klasse  {\em ab.jigsaw.sccs.SccsDirectoryRessource} ist.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6cm
\epsffile{Bilder/versionierung/classKontext.eps}
\end{center}
\caption{Ausschnitt der erweiterten Klassenhierarchie von {\jig}}
\label{classKontext}
\end{figure}
 
Die neue Ressourceklasse {\em ab.jigsaw.sccs.SccsDirectoryRessource} stellt die Verbindung zwischen den vorhandenen Serverklassen und der Abstraktion des SCCS her ({\VAB}~\ref{implKonzept}).

\subsubsection*{Konventionen f"ur die Benennung von Versionen}
Die Spezifizierung von Versionen einer Ressource erfolgt wie bei \cite{W96} durch eine Erweiterung der URI Syntax. Die Nutzung eines zus"atzlichen HTTP Nachrichtenkopfes in der Anfrage zur Spezifikation der Version einer Ressource w"urde u.a. eine Erweiterung der Client Software (dem {\brow}) erfordern und wurde verworfen, um die Unabh"angigkeit der Servererweiterung zu erhalten. Daten werden in dieser Implementierung u.a. "uber folgende URI Schemata angesprochen:
\begin{description}
\item[Protokoll://Rechnername/Pfad/Datei] Dies stellt den "ublichen Abruf einer Ressource dar.
\item[Protokoll://Rechnername/Pfad/SCCS] Der Zugriff auf ein SCCS Verzeichnis gibt dem Client in Form einer HTML Seite Informationen dar"uber, welche Dateien in welchen Versionen unter dem angegebenen Pfad vorhanden sind.
\item[Protokoll://Rechnername/Pfad/SCCS/Datei] Der Zugriff auf eine Datei in einem SCCS Verzeichnis liefert dem Client die Versionstopologie dieser Datei als HTML Seite.
\item[Protokoll://Rechnername/Pfad/SCCS/Datei;version=x.y] Dies stellt den Zu\-griff auf eine spezifische Version einer Datei dar. Dabei entspricht die Versionsnummer "'x.y"' dem Format der SCCS Versionsnummern.
\end{description}

\subsubsection*{Die Behandlung von HTTP Anfragen}
{\jig} Objekte behandeln HTTP Anfragen ({\VAS}~\ref{http}) nach Ressourcen im wesentlichen in zwei Methoden:
\begin{description}
\item [lookup:] Es wird gepr"uft, ob die von der Anfrage betroffene Ressource vorhanden ist. Ist das nicht der Fall wird eine Fehlermeldung erzeugt und an den Client ausgeliefert.
\item [perform:] Ist die Ressource vorhanden, wird die in der Anfrage enthaltene HTTP Methode auf der Ressource ausgef"uhrt. 
\end{description}

Durch Ableitung der Klasse {\em ab.jigsaw.sccs.SccsDirectoryRessource} von {\em w3c.jigsaw.resources. Resource}
werden diese Methoden vererbt und in der Subklasse "uberschrieben. 

Die {\em lookup} Methode der Klasse {\em ab.sccs.SccsDirectoryRessource} ist die Schnittstelle zum SCCS. Sie pr"uft, ob eine und wenn ja welche Benennungskonvention f"ur versionierte Daten verwendet wird und ob die gew"unschten Daten vorhanden sind. Dazu bedient sie sich der Hilfe der Klasse {\em ab.sccs.SccsDirectory}, die das Bindeglied der {\java} Datenstrukturen zum SCCS ({\VAB}~\ref{implKonzept}) bildet. Nach der "Uberpr"ufung wird die Zielressource der Anfrage bestimmt und --- falls noch nicht vorhanden --- erzeugt. Die {\em perform} Methode ruft entsprechend der in der {\em request line} ({\VAS}~\ref{http})  enthaltenen HTTP Methode die Methodenimplementation der durch die {\em lookup} Methode bestimmten Ressourceklasse auf. Die Implementation der HTTP GET Methode sorgt f"ur die Erstellung einer HTTP Serverantwort, die dieser an den Client "ubertr"agt.

Bei einem nicht vorhandenen SCCS Verzeichnis sowie einer in einem vorhandenen SCCS Verzeichnis nicht vorhandenen Datei wird eine Fehlermeldung erzeugt und an den Client "ubertragen. Im Fall einer nicht vorhandenen Version einer Ressource wird die Versionstopologie der Ressource ausgeliefert. An dieser Stelle sind auch andere Konfliktl"osungsstrategien denkbar, die z.B. bei einer nicht vorhandenen spezifischen Version die aktuellste oder die initiale Version einer Ressource ausliefern. SCCS erlaubt f"ur diese Zwecke die Definition einer Standardversion, die immer dann ausgew"ahlt wird, wenn keine Version einer Ressource spezifiziert wird.

\subsubsection*{Bewertung}
Im folgenden wird der Ansatz der Versionierung durch Anbindung vorhandener Systeme an WWW Server im Hinblick auf die in Abschnitt~\ref{verAnf} aufgestellten Anforderungen am Beispiel der vorgestellten Servererweiterung kritisch betrachtet.

\begin{description}
\item[Funktionale Anforderungen:] Die vorgestellte Implementierung zeigt, da"s die funktionalen Anforderungen des nur lesenden Benutzers im Gegensatz zu z.B. einer HTTP Erweiterung relativ einfach zu realisieren sind. Sollen per WWW auch neue Versionen erzeugt werden, sind aufwendigere L"osungen n"otig, da nicht nur Information vom Server zum {\brow} sondern  auch umgekehrt flie"sen mu"s. Eine L"osung daf"ur w"aren z.B. HTML Formulare und verarbeitende CGI Skripte ({\VAS}~\ref{verCGI}). Eine andere M"oglichkeit w"are die Realisierung mit Hilfe von mehreren in HTML {\em Frames} untergebrachten {\java} Applets, die f"ur die Kommunikation mit dem Server sorgen und "Anderungen propagieren.

\item[Technische Anforderungen:] Die oben beschriebene Implementierung ist nur zu dem {\jig} WWW Server kompatibel. Sofern sich allerdings die {\java} Servlet API ({\VAS}~\ref{code}) bei den Herstellern von Serversoftware durchsetzt, ist es mit deren Nutzung m"oglich, eine plattformunabh"angige und in jeden Server integrierbare Anbindung von Versionierungssystemen wie z.B. RCS und SCCS vorzunehmen. Die Flexibilit"at in Bezug auf die versionieren Datenformate sowie die effiziente Datenspeicherung h"angen nur von dem zugrundeliegenden Versionierungssystem ab. Transparenz und einfache Bedienbarkeit sind gegeben, da der nur lesende Benutzer lediglich einen erweiterten URL angeben mu"s, um eine versionierte Ressource anzufordern. Somit l"a"st sich das oben vorgestellte System von jedem {\brow} nutzen. 
\end{description}

Die Anbindung vorhandener Versionierungssysteme an vorhandene WWW Server stellt in dieser Reihe einen relativ einfach realisierbaren Ansatz dar. Vorhandene Systeme werden integriert und m"ussen nicht von Grund auf neu entwickelt werden, wie z.B. bei einer HTTP Erweiterung.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Zusammenfassung}
\label{verZus}
In diesem Kapitel wurde gezeigt, da"s Versionierungssysteme neben ihren eigentlichen Aufgaben --- wie z.B. der Bereitstellung von Historien von Objekten, der Unterst"utzung von kooperativer Arbeit mehrerer Entwickler an Objekten und der effizienten Verwaltung von Metadaten und Speicherplatz --- u.a. Unterst"utzung f"ur die  Konsistenzerhaltung von Hyperlinks und die Redundanzfreiheit bei der Speicherung von WWW Ressourcen bringen k"onnen. 

Nach einer Ein\-f"uhr\-ung in die grundlegenden Konzepte und die Terminologie wurden verschiedene Ans"atze zur Versionierung im WWW betrachtet sowie eine eigene Implementation vorgestellt. Die Bewertung der verschiedenen Ans"atze erlaubt die Auswahl einer geeigneten Versionierungsstrategie je nach beabsichtigtem Einsatzfeld.

Versionierung durch redundante Datenhaltung ({\VAS}~\ref{verRed}) bietet eine je nach gew"unschter Funktionalit"at einfache M"oglichkeit f"ur die Bereitstellung eines sehr flexiblen Versionierungssystems. Der Aufwand f"ur die Programmierung der verwaltenden Skripte sowie der Verbrauch von Speicherplatz sind jedoch nicht zu untersch"atzen.

Sollen lediglich HTML bzw. SGML Dokumente versioniert werden, bieten sich Ans"atze wie {\vtml} ({\VAS}~\ref{vtml}) an, die alle Versionen einer Ressource in einem Dokument speichern und "uber die erweiterte URL Adressierung die M"oglichkeit bieten, transparent auf versionierte Dokumente zuzugreifen. Da f"ur {\vtml} jedoch keine kommerziellen Werkzeuge (z.B. Editoren und Parser) vorliegen, ist die Anbindung eines bereits vorhandenen Versionierungssystems ({\VAS}~\ref{verCGI} oder Abschnitt~\ref{serverErw}) wie RCS oder SCCS einfacher realisierbar, da hier lediglich vorhandene Systeme integriert werden m"ussen.

Die umfassendste Funktionalit"at und Flexibilit"at bieten HTTP Erweiterungen ({\VAS}~\ref{verHTTP}), die allerdings durch die Erstellung neuer {\brow} und WWW Server auch den gr"o"sten Implementierungsaufwand erfordern. 




Im Zusammenhang mit der Hypertextstruktur des WWW sind technische L"osungen f"ur das Konfigurationsmanagement von weitergehendem Interesse. Konfigurationen entstehen, wenn bestimmte Versionen von Ressourcen Beziehungen zu spezifischen Versionen anderer Ressourcen z.B. "uber Hyperlinks aufbauen ({\VKA}~\ref{Kap. kontexte}).


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


