Diffstat (limited to 'development/pim/pimpaper/backendimplementation.tex') (more/less context) (ignore whitespace changes)
| -rw-r--r-- | development/pim/pimpaper/backendimplementation.tex | 53 |
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} |