Corrected text. I hope without distortion..

1 files changed, 28 insertions, 25 deletions

diff --git a/development/pim/pimpaper/backendimplementation.tex b/development/pim/pimpaper/backendimplementation.tex
index 272507a..a222be8 100644
--- a/development/pim/pimpaper/backendimplementation.tex
+++ b/development/pim/pimpaper/backendimplementation.tex
@@ -1,46 +1,49 @@
 \section{Implementation of the Backends}
-Opie Backends have implementations for XML, VCF and SQL. We can
-group the VCF and XML Backend in the File Family.
+Opie provides backend implementations for XML, VCF and SQL. XML and VCF are file based
+implementations, while the SQL backend use a real database.
 
 \section{Locking, Journal and Visibility}
 Opie PIM encourages that all changes are made visible 
-immediately and are propagated by Qt Signals by the Frontend
-but we recognize that not every Backend
-- specially the File Family - is capable of making every 
-change physically available instantly or it would be too
-complex to develop this is why this feature is nice to have
-but not necessary implement by the Backend.\\
-By default changes may not be lost by concurrent access and two different
-saves. The feature to implement is called Auto-Update the Backends
-can utilize QCOP for the communication. When one Backend saves the data
-it needs to lock the access (it can use API), check if external changes
-occurred and reload the data if necessary and then save the merged changes
-and finally to give up the lock.
-The user may call reload() any time and the access needs to be locked
-for that. The Backends can use the appropriate techniques to provide
-fast and secure operation.\\
-The reload feature may be turned off for the Frontend so that a save()
+immediately and are propagated via Qt Signals by the frontend.
+Due to performance issues, we recognize that not every backend
+implementation - especially the file based - is capable of making every 
+change physically available instantly, called ``Live Update''. It would be too complex to 
+implement this efficiently, thus we declare this as ``nice to have'' feature, 
+which may be implemented by the backend.\\
+By default changes should not be lost by concurrent access to the files. 
+The requested feature to avaoid this, is called ``Auto-Update''.  
+If one backend need to save the data, it has to lock the access (it can use API \comment{Was?}), check whether external changes
+occurred since last save and reload and merge the data, if necessary. This merging guarantees to include all external changes 
+to the local dataset. Afterwards it saves all data and removes the lock.
+\comment{ Was willst Du hier genau sagen? The user may call reload() at any time and the access needs to be locked
+for that.} The backends has to use the appropriate technique to provide
+fast and secure operations.\\
+\comment{Ich würde im Folgenden eher das vorschlagen:
+The reload feature may be turned off by the frontend to disable automatic update. In this case, the
+backend should work in ``read-only'' mode to prevent possible overwrite of changes}
+The reload feature may be turned off by the frontend so that a save()
 might possible override changes that occurred.
 
 \subsubsection{Journal and Out Of Memory}
-The Backend need to make sure that it is capable of surviving crashes
+The backend need to make sure that it is capable of surviving crashes
 and storage out of memory situation without losing data and changes.\\
-The File Family is encouraged to use the journal on a per user basis 
+The file based backends is encouraged to use a journal-file on a per user basis 
 to keep track of changes. The journal can be applied in case of a crash.\\
-In out of disk storage situation the user needs to be informed so it might
-free space.
+In out of disk storage situation the user needs to be informed, so he should get the chance to
+free space before the operation is stopped.
+Database based backends should use mechanisms which are provided or suggested for the database system, used.
 
-\subsubsection{Features of the Backends}
+\subsubsection{Features of the backends}
 
 \begin{center}
 \begin{tabular}{|l|l|l|l|l|}
 \hline
-Backend & Live Update & Auto Update & Journal  & Available\\ \hline
+backend & Live Update & Auto Update & Journal  & Available\\ \hline
 XML & no  & yes & no but SQL & after save \\ \hline
 SQL & yes & yes & yes        & immediately \\ \hline
 VCF & no  & no  & no         & never      \\ \hline
 \end{tabular}
-\label{Feature of Backends}
+\label{Feature of backends}
 \end{center}
 
 \subsection{Generic Implementation}