author | eilers <eilers> | 2004-09-01 15:36:15 (UTC) |
---|---|---|
committer | eilers <eilers> | 2004-09-01 15:36:15 (UTC) |
commit | ee5d578ea25ffdbda6b647e6dea93af77eb66d5f (patch) (unidiff) | |
tree | 81afd4c707db2e71422723d5540d6d7a37e44b87 /development/pim | |
parent | dc30b84bb9c3759bcfee5e6d162395cad9873465 (diff) | |
download | opie-ee5d578ea25ffdbda6b647e6dea93af77eb66d5f.zip opie-ee5d578ea25ffdbda6b647e6dea93af77eb66d5f.tar.gz opie-ee5d578ea25ffdbda6b647e6dea93af77eb66d5f.tar.bz2 |
Corrected text. I hope without distortion..
-rw-r--r-- | development/pim/pimpaper/backend.tex | 22 | ||||
-rw-r--r-- | development/pim/pimpaper/backendimplementation.tex | 53 | ||||
-rw-r--r-- | development/pim/pimpaper/frontend.tex | 24 | ||||
-rw-r--r-- | development/pim/pimpaper/gui_xref.tex | 44 | ||||
-rw-r--r-- | development/pim/pimpaper/introduction.tex | 2 | ||||
-rw-r--r-- | development/pim/pimpaper/opiepim.tex | 10 | ||||
-rw-r--r-- | development/pim/pimpaper/seperation.tex | 91 |
7 files changed, 129 insertions, 117 deletions
diff --git a/development/pim/pimpaper/backend.tex b/development/pim/pimpaper/backend.tex index 2652b08..fcade7f 100644 --- a/development/pim/pimpaper/backend.tex +++ b/development/pim/pimpaper/backend.tex | |||
@@ -1,17 +1,17 @@ | |||
1 | \section{The Backend Design} | 1 | \section{The Backend Design} |
2 | 2 | ||
3 | \subsection{The Template} | 3 | \subsection{The Template} |
4 | OPimAccessBackend is a template interface of the Backend. | 4 | OPimAccessBackend is a template interface of the backend. |
5 | It consists out of pure virtual functions to implement for | 5 | It consists out of pure virtual functions for |
6 | load, reload, save and clear. You will also need to implement | 6 | load, reload, save and clear, add, remove and replace. |
7 | add, remove and replace. | 7 | Special inheritances from OPimAccessBackend for todo, calendar-event and conatact are available to |
8 | Todo, Event and Address inherit from OPimAccessBackend to create | 8 | define the backend Type with additional functionality and some implementations for special queries. |
9 | their Backend Type with additional functionality and also some | ||
10 | default implementation for some queries. | ||
11 | 9 | ||
12 | \subsection{Read Ahead} | 10 | \subsection{Caching} |
13 | You may implement Read Ahead or Read Behind by implementing | 11 | You may implement caching by implementing a specific find function. It is filling the cache |
14 | the specific find function. First you need to give the Frontend | 12 | (located in the frontend) as read-ahed or read-behing, by giving a read direction. |
13 | \comment{ Das versteht an dieser Stelle keiner: First you need to give the Frontend | ||
15 | a hint on how many items you want to cache and then you can call | 14 | a hint on how many items you want to cache and then you can call |
16 | cache to cache items. | 15 | cache to cache items. |
17 | read Ahead returns the number of Records to read behind/ahead. | 16 | read-ahead returns the number of records to read behind/ahead.} |
17 | Caching is used automatically, if this function is implemented. | ||
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,51 +1,54 @@ | |||
1 | \section{Implementation of the Backends} | 1 | \section{Implementation of the Backends} |
2 | Opie Backends have implementations for XML, VCF and SQL. We can | 2 | Opie provides backend implementations for XML, VCF and SQL. XML and VCF are file based |
3 | group the VCF and XML Backend in the File Family. | 3 | implementations, while the SQL backend use a real database. |
4 | 4 | ||
5 | \section{Locking, Journal and Visibility} | 5 | \section{Locking, Journal and Visibility} |
6 | Opie PIM encourages that all changes are made visible | 6 | Opie PIM encourages that all changes are made visible |
7 | immediately and are propagated by Qt Signals by the Frontend | 7 | immediately and are propagated via Qt Signals by the frontend. |
8 | but we recognize that not every Backend | 8 | Due to performance issues, we recognize that not every backend |
9 | - specially the File Family - is capable of making every | 9 | implementation - especially the file based - is capable of making every |
10 | change physically available instantly or it would be too | 10 | change physically available instantly, called ``Live Update''. It would be too complex to |
11 | complex to develop this is why this feature is nice to have | 11 | implement this efficiently, thus we declare this as ``nice to have'' feature, |
12 | but not necessary implement by the Backend.\\ | 12 | which may be implemented by the backend.\\ |
13 | By default changes may not be lost by concurrent access and two different | 13 | By default changes should not be lost by concurrent access to the files. |
14 | saves. The feature to implement is called Auto-Update the Backends | 14 | The requested feature to avaoid this, is called ``Auto-Update''. |
15 | can utilize QCOP for the communication. When one Backend saves the data | 15 | If one backend need to save the data, it has to lock the access (it can use API \comment{Was?}), check whether external changes |
16 | it needs to lock the access (it can use API), check if external changes | 16 | occurred since last save and reload and merge the data, if necessary. This merging guarantees to include all external changes |
17 | occurred and reload the data if necessary and then save the merged changes | 17 | to the local dataset. Afterwards it saves all data and removes the lock. |
18 | and finally to give up the lock. | 18 | \comment{ Was willst Du hier genau sagen? The user may call reload() at any time and the access needs to be locked |
19 | The user may call reload() any time and the access needs to be locked | 19 | for that.} The backends has to use the appropriate technique to provide |
20 | for that. The Backends can use the appropriate techniques to provide | 20 | fast and secure operations.\\ |
21 | fast and secure operation.\\ | 21 | \comment{Ich würde im Folgenden eher das vorschlagen: |
22 | The reload feature may be turned off for the Frontend so that a save() | 22 | The reload feature may be turned off by the frontend to disable automatic update. In this case, the |
23 | backend should work in ``read-only'' mode to prevent possible overwrite of changes} | ||
24 | The reload feature may be turned off by the frontend so that a save() | ||
23 | might possible override changes that occurred. | 25 | might possible override changes that occurred. |
24 | 26 | ||
25 | \subsubsection{Journal and Out Of Memory} | 27 | \subsubsection{Journal and Out Of Memory} |
26 | The Backend need to make sure that it is capable of surviving crashes | 28 | The backend need to make sure that it is capable of surviving crashes |
27 | and storage out of memory situation without losing data and changes.\\ | 29 | and storage out of memory situation without losing data and changes.\\ |
28 | The File Family is encouraged to use the journal on a per user basis | 30 | The file based backends is encouraged to use a journal-file on a per user basis |
29 | to keep track of changes. The journal can be applied in case of a crash.\\ | 31 | to keep track of changes. The journal can be applied in case of a crash.\\ |
30 | In out of disk storage situation the user needs to be informed so it might | 32 | In out of disk storage situation the user needs to be informed, so he should get the chance to |
31 | free space. | 33 | free space before the operation is stopped. |
34 | Database based backends should use mechanisms which are provided or suggested for the database system, used. | ||
32 | 35 | ||
33 | \subsubsection{Features of the Backends} | 36 | \subsubsection{Features of the backends} |
34 | 37 | ||
35 | \begin{center} | 38 | \begin{center} |
36 | \begin{tabular}{|l|l|l|l|l|} | 39 | \begin{tabular}{|l|l|l|l|l|} |
37 | \hline | 40 | \hline |
38 | Backend & Live Update & Auto Update & Journal & Available\\ \hline | 41 | backend & Live Update & Auto Update & Journal & Available\\ \hline |
39 | XML & no & yes & no but SQL & after save \\ \hline | 42 | XML & no & yes & no but SQL & after save \\ \hline |
40 | SQL & yes & yes & yes & immediately \\ \hline | 43 | SQL & yes & yes & yes & immediately \\ \hline |
41 | VCF & no & no & no & never \\ \hline | 44 | VCF & no & no & no & never \\ \hline |
42 | \end{tabular} | 45 | \end{tabular} |
43 | \label{Feature of Backends} | 46 | \label{Feature of backends} |
44 | \end{center} | 47 | \end{center} |
45 | 48 | ||
46 | \subsection{Generic Implementation} | 49 | \subsection{Generic Implementation} |
47 | \subsubsection{Recurrence} | 50 | \subsubsection{Recurrence} |
48 | FIXME | 51 | FIXME |
49 | \subsubsection{OPimState} | 52 | \subsubsection{OPimState} |
50 | FIXME | 53 | FIXME |
51 | \subsubsection{Reminders and Alarms} | 54 | \subsubsection{Reminders and Alarms} |
diff --git a/development/pim/pimpaper/frontend.tex b/development/pim/pimpaper/frontend.tex index 1ed41aa..9c46c07 100644 --- a/development/pim/pimpaper/frontend.tex +++ b/development/pim/pimpaper/frontend.tex | |||
@@ -1,24 +1,24 @@ | |||
1 | \section{Frontend} | 1 | \section{Frontend} |
2 | 2 | ||
3 | \subsection{Low Level Frontend} | 3 | \subsection{Low Level Frontend} |
4 | OPimBase is a low level not value based interface, to do basic queries | 4 | For general (typeless) operations, OPimBase provides a real low level, reference based, interface, for basic queries |
5 | and record finding in a generic way. It is present to allow | 5 | and record finding. These operations are common to all frontends. |
6 | generic access to all Frontends. | ||
7 | 6 | ||
8 | \subsection{OTemplateBase} | 7 | \subsection{OTemplateBase} |
9 | Inherits from OPimBase and implements bits of the OPimBase Interface. | 8 | Inherited from OPimBase and implements bits \comment{bits? Teile ? Welche Teile ? Sollte es nicht eher vervollständigen heissen?} of the OPimBase Interface. |
10 | This class is present to be used by the Backends ( OPimAccessBackend ) | 9 | This class is present to be used by the Backends ( OPimAccessBackend ) |
11 | to set cache sizes and to cache items. | 10 | to set cache sizes and to cache items. |
12 | 11 | ||
13 | \subsection{OPimAccessTemplate} | 12 | \subsection{OPimAccessTemplate} |
14 | Implements OTemplateBase and OPimBase. All low level functions are | 13 | Implements OTemplateBase and OPimBase. All low level functions are |
15 | automatically implemented by the OPimAccessTemplate which does | 14 | automatically implemented by the OPimAccessTemplate which does |
16 | additional type checking based on OPimRecord::rtti.\\ | 15 | additional type checking, based on OPimRecord::rtti.\\ |
17 | This template is value based and utilizes the Backend. The Backend | 16 | This template is value based and utilizes the backend. The backend |
18 | can be set on the Constructor, when no Backend is specified | 17 | can be set on instancing by the constructor. If no backend is specified, |
19 | the default Backend Implementation will be used. | 18 | the default implementation will be used (which one is defined by the config file |
20 | This AccessTemplate operates on OPimRecord based types and is meant | 19 | pimaccess.conf). |
21 | to be used by concrete Frontend implementations for Todo, Event, | 20 | This AccessTemplate operates on types, based on OPimRecord and is meant |
22 | Note and Address. The concrete Frontends can be used by applications. | 21 | to be used by concrete frontend implementations for todo, datebook-event, |
23 | Use this template to create your own PIM Type. | 22 | note and contact. The concrete frontends can be used by applications. |
23 | Use this template to create new PIM types. | ||
24 | 24 | ||
diff --git a/development/pim/pimpaper/gui_xref.tex b/development/pim/pimpaper/gui_xref.tex index d869c5f..f86e618 100644 --- a/development/pim/pimpaper/gui_xref.tex +++ b/development/pim/pimpaper/gui_xref.tex | |||
@@ -1,40 +1,44 @@ | |||
1 | \section{GUI Classes} | 1 | \section{GUI Classes} |
2 | GUI elements should be provided for modifying records in a general way. The next sections | ||
3 | shows suggested widgets for this purpose. | ||
2 | 4 | ||
3 | \subsubsection{Recurrence Widget} | 5 | \subsubsection{Recurrence Widget} |
4 | Opie PIM offers a recurrence Widget to let the user | 6 | Opie PIM offers a recurrence widget to let the user |
5 | configure the recurrence. | 7 | configure the recurrence. |
6 | 8 | ||
7 | \subsubsection{Mainwindow} | 9 | \subsubsection{Mainwindow} |
8 | The mainwindow implements a QCOP Interface for showing, | 10 | The mainwindow implements a QCOP interface for showing and |
9 | editing records. It can handle alarms and reminder activation. | 11 | editing records. It can handle alarms and reminder activation. |
10 | 12 | ||
11 | \section{Cross Reference} | 13 | \section{Cross Reference} |
12 | 14 | ||
13 | \subsection{The idea} | 15 | \subsection{The idea} |
14 | Sometimes an Event or Todo is related to something else. | 16 | Sometimes a datebook-event or todo is related to something else. |
15 | For example the Birthday Attribute of your children Record relate | 17 | For example, the birthday attribute of a child record relate |
16 | to the Birthday Event in your Datebook and the ``Book clown'' | 18 | to the birthday event in a datebook and to the entry ``Book clown'' |
17 | in your Todolist.\\ | 19 | in your todolist.\\ |
18 | We need a way to select the Record and the attribute if we want | 20 | We need a way to interconnect information to describe such relations. |
19 | that fine grained information. | ||
20 | 21 | ||
21 | \subsection{Selecting the Reference} | 22 | \subsection{Selecting the Reference} |
22 | \subsubsection{Out Of Process Selection} | 23 | \subsubsection{Out Of Process Selection} |
23 | For an Out of Process solution we could utilize the targeted | 24 | For an out of process solution, we could utilize the targeted |
24 | Application to request the selection of an record.\\ | 25 | application to request the selection of an record.\\ |
25 | For that to work we need to know which application offers | 26 | For that to work we need to know which application offers |
26 | Cross Referencing and the API needs to be able to find the | 27 | cross referencing. The API needs to be able to find the |
27 | application and then call them via QCOP.\\ | 28 | application and then call them via QCOP.\\ |
28 | Later for resolving the Cross Reference the same application\\ | 29 | Later, for resolving the cross-references, the same application\\ |
29 | would be either asked to give a summary string or it could | 30 | would be either asked to give a summary string or it could |
30 | display the reference on demand. This requires the application | 31 | display the reference on demand. This requires the application |
31 | to start and a specific selection window, but more easily | 32 | to start a specific selection window, but more easily |
32 | allows to cross reference attributes. | 33 | allows to cross reference attributes. \comment{``, but..'' Das verstehe ich nicht!. Ich wuerde den Satz so uebersetzen: |
34 | Dies erfordert, dass die Application ein spezielles Auswahlfenster startet, aber viel einfacher die | ||
35 | Crossreferenzierung von Attributen erlaubt. | ||
36 | Meinst Du das ? } | ||
33 | 37 | ||
34 | \subsubsection{In Process Selection} | 38 | \subsubsection{In-Process-Selection} |
35 | In Process Selection is possible with the usage of OPimBase | 39 | In-process-selection is possible using OPimBase |
36 | and OPimRecord. It allows to query and sort in a generic way. | 40 | and OPimRecord. It allows to query and sort in a generic way. |
37 | This would allow to have a generic Selector widget which | 41 | This would allow to have a generic selector widget, which |
38 | can be used to select a Record and possible files as well. To | 42 | can be used to select a record and possible files as well. To |
39 | support new types one could dlopen the Frontends to allow | 43 | support new types it should be possible to use plugins (via dlopen) do load |
40 | custom Frontends. | 44 | and support custom frontends. |
diff --git a/development/pim/pimpaper/introduction.tex b/development/pim/pimpaper/introduction.tex index 24cf586..5241d5e 100644 --- a/development/pim/pimpaper/introduction.tex +++ b/development/pim/pimpaper/introduction.tex | |||
@@ -1,14 +1,14 @@ | |||
1 | \section{Introduction} | 1 | \section{Introduction} |
2 | 2 | ||
3 | \subsection{This Document} | 3 | \subsection{This Document} |
4 | This paper will describe the design decision, our specification | 4 | This paper will describe the design decision, our specification |
5 | and how it integrates into C++, Qt and Opie. | 5 | and how it integrates into C++, Qt and Opie. |
6 | It will examine the separation between Frontend and Backend, delayed | 6 | It will examine the separation between Frontend and Backend, delayed |
7 | loading of Records, the concrete XML, SQL and VCF implementation | 7 | loading of Records, the concrete XML, SQL and VCF implementation |
8 | of the Backend and finally we will built a new Frontend/Backend | 8 | of the Backend and finally, we will built a new Frontend/Backend |
9 | to support a Note based API. | 9 | to support a Note based API. |
10 | 10 | ||
11 | \subsection{Copyright} | 11 | \subsection{Copyright} |
12 | 12 | ||
13 | Copyright notice | 13 | Copyright notice |
14 | \copyright 2004, Holger Hans Peter Freyther | 14 | \copyright 2004, Holger Hans Peter Freyther |
diff --git a/development/pim/pimpaper/opiepim.tex b/development/pim/pimpaper/opiepim.tex index 0b26083..89e6292 100644 --- a/development/pim/pimpaper/opiepim.tex +++ b/development/pim/pimpaper/opiepim.tex | |||
@@ -1,15 +1,17 @@ | |||
1 | \documentclass [12pt,a4paper]{article} | 1 | \documentclass [12pt,a4paper]{article} |
2 | \usepackage{german} | 2 | \usepackage{german} |
3 | \usepackage[latin1]{inputenc} | 3 | \usepackage[latin1]{inputenc} |
4 | \pagestyle{headings} | 4 | \pagestyle{headings} |
5 | \usepackage{epsfig} | 5 | \usepackage{epsfig} |
6 | \usepackage{graphicx} | 6 | \usepackage{graphicx} |
7 | 7 | ||
8 | \newcommand{\comment}[1]{} | ||
9 | |||
8 | \begin{document} | 10 | \begin{document} |
9 | 11 | ||
10 | \begin{titlepage} | 12 | \begin{titlepage} |
11 | 13 | ||
12 | \begin{center} | 14 | \begin{center} |
13 | \Huge{Opie PIM Design and Implementation} | 15 | \Huge{Opie PIM Design and Implementation} |
14 | \Large{\\pre beta\\} | 16 | \Large{\\pre beta\\} |
15 | \Large{\today} | 17 | \Large{\today} |
@@ -24,18 +26,22 @@ | |||
24 | \end{minipage} | 26 | \end{minipage} |
25 | \end{figure} | 27 | \end{figure} |
26 | 28 | ||
27 | \end{center} | 29 | \end{center} |
28 | 30 | ||
29 | \vfill | 31 | \vfill |
30 | \centerline{ | 32 | \centerline{ |
31 | \begin{tabular}[t]{|c|c|c|} \hline | 33 | \begin{tabular}[t]{|c|c|c|} \hline |
32 | \textbf{Version} & \textbf{Author} & \textbf{Email} \\ \hline\hline | 34 | \textbf{Version} & \textbf{Author} & \textbf{Email} \\ |
33 | 0.0.1 & Holger Freyther & zecke@handhelds.org \\ \hline | 35 | \hline\hline |
36 | 0.0.1 & Holger Freyther & zecke@handhelds.org \\ | ||
37 | \hline | ||
38 | 0.0.2 & Stefan Eilers & eilers.stefan@epost.de \\ | ||
39 | \hline | ||
34 | \end{tabular} | 40 | \end{tabular} |
35 | } | 41 | } |
36 | 42 | ||
37 | \end{titlepage} | 43 | \end{titlepage} |
38 | 44 | ||
39 | \tableofcontents{} | 45 | \tableofcontents{} |
40 | \pagebreak | 46 | \pagebreak |
41 | 47 | ||
diff --git a/development/pim/pimpaper/seperation.tex b/development/pim/pimpaper/seperation.tex index 544d5c1..e865fb0 100644 --- a/development/pim/pimpaper/seperation.tex +++ b/development/pim/pimpaper/seperation.tex | |||
@@ -1,66 +1,65 @@ | |||
1 | \section{Components of Opie PIM} | 1 | \section{Components of Opie PIM} |
2 | 2 | ||
3 | \subsection{The Record} | 3 | \subsection{The Record} |
4 | With our API everything is based on a OPimRecord, this record | 4 | The basic component of our API is the OPimRecord. Every record is identified |
5 | got a Identifier which is unique to the Backend it belongs, it is | 5 | by an identifier, which is unique to the backend it belongs to |
6 | also possible to assign a new Unique Identifier (uid) on a newly | 6 | \comment{Why it is just unique to the backend? (eilers)}. |
7 | If expected, is also possible to assign a new Unique Identifier (UID) on a newly | ||
7 | created OPimRecord.\\ | 8 | created OPimRecord.\\ |
8 | The OPimRecord allows to assign Categories this record is in, to get | 9 | The OPimRecord allows to be assigned to categories, to provide a Rich Text |
9 | a Rich Text summary of the content of the Record and finally to match | 10 | summary of its content and finally to match |
10 | the content of the Record with a regular expression. | 11 | the content of the Record with a regular expression. |
11 | 12 | ||
12 | \subsection{The Frontend} | 13 | \subsection{The Frontend} |
13 | Opie PIM got Frontends to access Todos, Events and Addressees. Using | 14 | Opie PIM implements frontends to access Todos, Datebook-Events and Addresses. |
14 | the default Constructor of either OTodoAccess, ODatebookAccess or | 15 | The frontend provides a value based interface and operates on records inherited |
15 | OContactAccess uses the default data. These Access methods offer | 16 | from OPimRecord and add extra task specific methods to it. |
16 | the common load, save, clear, reload methods and have all in common | 17 | |
17 | to query for an example record, sort a list of records for specific | 18 | Access methods offer the common load, save, clear, reload methods, |
18 | characteristics, and to match the content against a regular expression | 19 | give access to the records inside the database/storage and implement a general |
19 | and give access to the Records inside the database/storage.\\ | 20 | interface to query, for example, a record, request a sorted lists of records for specific |
20 | The Frontend provide a value based Interface and operates on Records | 21 | characteristics and to match the content against a regular expression.\\ |
21 | that inherit from OPimRecord and add extra task specific methods to it. | ||
22 | 22 | ||
23 | \subsection{ORecordList and Iterator} | 23 | \subsection{ORecordList and Iterator} |
24 | The result of a query or the content of the database is a ORecordList. | 24 | The result of a query or the content of the database is is abstracted by an ORecordList. |
25 | To iterate over a ORecordList you can use the Iterator. The Iterators | 25 | To iterate over an ORecordList useing an Iterator. |
26 | behaves like the Iterators found in Qt and on dereferencing you get | 26 | Using STL like iterators, it is possible to iterate through an ORecordList. |
27 | the reference to the record. Internally the record is fetched just | 27 | Accessing a record is easy possible by dereferencing the iterator. |
28 | in time. This delayed loading allows to exploit full power of the specific | 28 | Internally, the record is fetched just in time, called delayed loading. |
29 | Backend. | 29 | This delayed loading allows to exploit \comment{exploit??} full power of the specific |
30 | backend. | ||
30 | 31 | ||
31 | 32 | ||
32 | \subsection{The Backend} | 33 | \subsection{The Backend} |
33 | The Backend is a template based interface that operates on OPimRecord | 34 | The backend is a template based interface that operates on data types, inherited from OPimRecord. |
34 | inherited data types. To implement the delayed loading the Backends | 35 | Delayed loading is implemented by the idea of storing just a list of UIDs instead complete records |
35 | Implementation return only a list of UIDs and these get converted | 36 | in an OPimRecordList<T> by the frontend and to fetch the records just on demand. |
36 | to a OPimRecordList<T> by the Frontend. | ||
37 | 37 | ||
38 | \subsection{The cache and read ahead} | 38 | \subsection{Caching} |
39 | To speed up the repeated lookup of records, specially when iterating | 39 | To speed up the repeated lookup of records, especially while iterating |
40 | over the OPimRecordList we've a cache in the Frontend which is filled | 40 | over the OPimRecordList, a caching mechanism, located in the frontend, is filled |
41 | by the Backend and specially in the iterator case the Backend | 41 | by the backend automatically. |
42 | can do a read ahead to fill the cache. | ||
43 | 42 | ||
44 | \subsection{Backend vs. Frontend} | 43 | \subsection{Backend vs. Frontend} |
45 | The Frontend is meant to be used by the normal API user to access | 44 | The frontend is meant to be used by the user API to access |
46 | and query the Records and to save it with different Backend to | 45 | and query the Records. \comment{ Ist hier irrelevant und verwirrt: and to save it with different backend to |
47 | a different file if needed. | 46 | a different file if needed}. |
48 | The Backend is used to implement concrete storage such as XML, VCF | 47 | The backend is used to implement the real storage, such as XML, VCF |
49 | and SQL and exploit possible features of the chosen storage. For example | 48 | and SQL and exploit \comment{exploit?} special features of the chosen storage. For example |
50 | a SQL Backend can use the power of query, lookup, sorting of the database | 49 | a SQL backend can use the power of query, lookup, sorting of the database |
51 | and do true delayed loading of records whereas the XML resource on | 50 | and do true delayed loading of records whereas the XML resource on |
52 | a simple file-system normally can't (XMLLiveConnect on ReiserFS). On remote | 51 | a simple file-system normally can't (XMLLiveConnect on ReiserFS\comment{???}). |
53 | Backends such as LDAP one might want to use delayed initialisation and | 52 | On remote backends, such as LDAP, one might want to use delayed initialisation and |
54 | fetching of records as well. Due the clean separation of Frontend and Backend | 53 | fetching of records as well. Due to the clean separation of frontend and backend, |
55 | this is possible but the ease of development and deployment | 54 | it is possible to use the power of the used databases, but still keep the ease of development |
56 | of both Backends and Frontend remain. | 55 | and deployment. |
57 | 56 | ||
58 | \subsection{Occurrences} | 57 | \subsection{Occurrences} |
59 | A Frontend/Backend can be queried to include OPimRecords for a | 58 | A frontend/backend can be queried to provide OPimRecords which occur in a |
60 | period of time. Traditionally this only applies to Events but | 59 | period of time. Traditionally this only applies to Calendar-Events, but |
61 | with the Opie1.2 revision of PIM this can also be applied to | 60 | due to the the revision of Opie (release 1.2), this can also be applied to |
62 | Todo, Address and Notes. | 61 | Todo, Address and Notes, as well. |
63 | It behaves similar to OPimRecordList and supports the delayed | 62 | OPimOccurence behaves similar to OPimRecordList and supports the delayed |
64 | loading of Records. | 63 | loading of Records as described above. |
65 | 64 | ||
66 | %TODO implement it.... :} | 65 | %TODO implement it.... :} |