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
|
\section{Components of Opie PIM}
\subsection{The Record}
The basic component of our API is the OPimRecord. Every record is identified
by an identifier, which is unique to the backend it belongs to
\comment{Why it is just unique to the backend? (eilers)}.
If expected, is also possible to assign a new Unique Identifier (UID) on a newly
created OPimRecord.\\
The OPimRecord allows to be assigned to categories, to provide a Rich Text
summary of its content and finally to match
the content of the Record with a regular expression.
\subsection{The Frontend}
Opie PIM implements frontends to access Todos, Datebook-Events and Addresses.
The frontend provides a value based interface and operates on records inherited
from OPimRecord and add extra task specific methods to it.
Access methods offer the common load, save, clear, reload methods,
give access to the records inside the database/storage and implement a general
interface to query, for example, a record, request a sorted lists of records for specific
characteristics and to match the content against a regular expression.\\
\subsection{ORecordList and Iterator}
The result of a query or the content of the database is is abstracted by an ORecordList.
To iterate over an ORecordList useing an Iterator.
Using STL like iterators, it is possible to iterate through an ORecordList.
Accessing a record is easy possible by dereferencing the iterator.
Internally, the record is fetched just in time, called delayed loading.
This delayed loading allows to exploit \comment{exploit??} full power of the specific
backend.
\subsection{The Backend}
The backend is a template based interface that operates on data types, inherited from OPimRecord.
Delayed loading is implemented by the idea of storing just a list of UIDs instead complete records
in an OPimRecordList<T> by the frontend and to fetch the records just on demand.
\subsection{Caching}
To speed up the repeated lookup of records, especially while iterating
over the OPimRecordList, a caching mechanism, located in the frontend, is filled
by the backend automatically.
\subsection{Backend vs. Frontend}
The frontend is meant to be used by the user API to access
and query the Records. \comment{ Ist hier irrelevant und verwirrt: and to save it with different backend to
a different file if needed}.
The backend is used to implement the real storage, such as XML, VCF
and SQL and exploit \comment{exploit?} special 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\comment{???}).
On remote backends, such as LDAP, one might want to use delayed initialisation and
fetching of records as well. Due to the clean separation of frontend and backend,
it is possible to use the power of the used databases, but still keep the ease of development
and deployment.
\subsection{Occurrences}
A frontend/backend can be queried to provide OPimRecords which occur in a
period of time. Traditionally this only applies to Calendar-Events, but
due to the the revision of Opie (release 1.2), this can also be applied to
Todo, Address and Notes, as well.
OPimOccurence behaves similar to OPimRecordList and supports the delayed
loading of Records as described above.
%TODO implement it.... :}
|
