First Draft of Opie PIM Paper

Giving an Overview and Reference for the used Attributes  of
the Backends

1 files changed, 66 insertions, 0 deletions

diff --git a/development/pim/pimpaper/seperation.tex b/development/pim/pimpaper/seperation.tex
new file mode 100644
index 0000000..544d5c1
--- a/dev/null
+++ b/development/pim/pimpaper/seperation.tex
@@ -0,0 +1,66 @@
+\section{Components of Opie PIM}
+
+\subsection{The Record}
+With our API everything is based on a  OPimRecord, this record
+got a Identifier which is unique to the Backend it belongs, it is
+also possible to assign a new Unique Identifier (uid) on a newly
+created OPimRecord.\\
+The OPimRecord allows to assign Categories this record is in, to get
+a Rich Text summary of the content of the Record and finally to match 
+the content of the Record with a regular expression.
+
+\subsection{The Frontend}
+Opie PIM got Frontends to access Todos, Events and Addressees. Using
+the default Constructor of either OTodoAccess, ODatebookAccess or
+OContactAccess uses the default data. These Access methods offer
+the common load, save, clear, reload methods and have all in common
+to query for an example record, sort a list of records for specific
+characteristics, and to match the content against a regular expression
+ and give access to the Records inside the database/storage.\\
+The Frontend provide a value based Interface and operates on Records
+that inherit from OPimRecord and add extra task specific methods to it.
+
+\subsection{ORecordList and Iterator}
+The result of a query or the content of the database is a ORecordList.
+To iterate over a ORecordList you can use the Iterator. The Iterators
+behaves like the Iterators found in Qt and on dereferencing you get
+the reference to the record. Internally the record is fetched just
+in time. This delayed loading allows to exploit full power of the specific
+Backend.
+
+
+\subsection{The Backend}
+The Backend is a template based interface that operates on OPimRecord
+inherited data types. To implement the delayed loading the Backends
+Implementation return only a list of UIDs and these get converted
+to a OPimRecordList<T> by the Frontend.
+
+\subsection{The cache and read ahead}
+To speed up the repeated lookup of records, specially when iterating
+over the OPimRecordList we've a cache in the Frontend which is filled
+by the Backend and specially in the iterator case the Backend
+can do a read ahead to fill the cache.
+
+\subsection{Backend vs. Frontend}
+The Frontend is meant to be used by the normal API user to access
+and query the Records and to save it with  different Backend to
+a different file if needed.
+The Backend is used to implement concrete storage such as XML, VCF
+and SQL and exploit possible features of the chosen storage. For example
+a SQL  Backend can use the power of query, lookup, sorting of the database
+and do true delayed loading of records whereas the XML resource on
+a simple file-system normally can't (XMLLiveConnect on ReiserFS). On remote
+Backends such as LDAP one might want to use delayed initialisation and
+fetching of records as well. Due the clean separation of Frontend and Backend
+this is possible but the ease of development and deployment 
+of both Backends and Frontend remain.
+
+\subsection{Occurrences}
+A Frontend/Backend can be queried to include OPimRecords for a 
+period of time. Traditionally this only applies to Events but 
+with the Opie1.2 revision of PIM this can also be applied to
+Todo, Address and Notes.
+It behaves similar to OPimRecordList and supports the delayed
+loading of Records.
+ 
+%TODO implement it.... :}