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