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,103 +1,106 @@
 \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}
 \subsubsection{Recurrence}
 FIXME
 \subsubsection{OPimState}
 FIXME
 \subsubsection{Reminders and Alarms}
 
 \subsection{Todo}
 \subsubsection{XML}
 
 % supported attributes
 \begin{tabular}{|l|l|}
 \hline
 Key            & Possible Values \\ \hline
 Categories     & Comma separated list of Integers \\ \hline
 Uid            & Unique negative Integer generated by timet \\ \hline
 HasDate        & 0 for false and 1 for true \\ \hline
 Completed      & 1 for completed and 0 for not completed \\ \hline
 Description    & Escaped multi line Text \\ \hline
 Summary        & One line summary \\ \hline
 Priority       & Between 0 and 5, 5 high priority \\ \hline
 DateDay        & The Day for the DueDate \\ \hline
 DateMonth      & The Month for the DueDate \\ \hline
 DateYear       & The year for the DueDate \\ \hline
 Progress       & 0,10,20,30,40,50,60,70,80,90,100 \\ \hline
 CompleteDate   & YYYYMMDD formated Date \\ \hline
 StartDate      & YYYYMMDD formated Date \\ \hline
 CrossReference & TODO!!  \\ \hline
 State          & Relates to OPimState 0-4 arre current values \\ \hline
 Alarms         & YYYYMMDD:durationOfTheAlarm:sound:future 
                  multiple alarams are joined with ; \\ \hline
 Reminders      & Notused TODO!!! \\ \hline
 rtype          & Daily, Weekly, MonthlyDay, MonthlyDate, Yearly, None\\ \hline
 rweekdays      & Char OPimReccruence::Days ored together \\ \hline
 rposition      & The day in the week TODO\\ \hline
 rfreq          & Every n (as int) \\ \hline
 start          & The creation of the recurrence in UTC time\\ \hline
 rhasenddate    & 1 if the recurrence has an end \\ \hline
 enddt          & The end date of the recurrence from UTC time\\ \hline
 \end{tabular}
 
 \subsubsection{VCF}
 
 
 \subsubsection{SQL}
 
 
 \subsection{Contact}
 \subsubsection{XML}
 \subsubsection{VCF}
 \subsubsection{SQL}
 
 
 \subsection{Datebook}
 \subsubsection{XML}
 \subsubsection{VCF}
 \subsubsection{SQL}