1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
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.... :}
|
