Diffstat (limited to 'development/pim/pimpaper/seperation.tex') (more/less context) (show whitespace changes)
-rw-r--r-- | development/pim/pimpaper/seperation.tex | 91 |
1 files changed, 45 insertions, 46 deletions
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.... :} |