1.1 --- a/docs/wiki/Developing Sun Mar 06 00:11:29 2016 +0100
1.2 +++ b/docs/wiki/Developing Sun Mar 06 00:44:42 2016 +0100
1.3 @@ -61,10 +61,6 @@
1.4 `imip_manager.py`
1.5 || The [[../CalendarManager|management interface]] main program file
1.6 ==
1.7 -`imip_store.py`
1.8 -|| The Python module providing an abstraction over the
1.9 -.. [[../FilesystemUsage|data storage structures]]
1.10 -==
1.11 `markup.py`
1.12 || A Python library providing HTML generation support
1.13 ==
1.14 @@ -112,6 +108,22 @@
1.15 system client, typically handling a single calendar object at any given
1.16 time.
1.17
1.18 +The `imiptools.stores` package provides the basis for calendar data
1.19 +persistence. From the very start, the nature of data organisation for
1.20 +calendar users was centred on the storage of each user's free/busy records,
1.21 +since the priority was to generate such records from messages exchanged
1.22 +over e-mail, and the use of plain text files was chosen as the simplest
1.23 +and most transparent approach. Beyond this, the need to retain calendar
1.24 +objects arose, and thus a [[../FilesystemUsage|filesystem-based approach]]
1.25 +was cultivated to manage such data.
1.26 +
1.27 +In the future, other persistence mechanisms could be supported. However,
1.28 +aside from performance concerns around access to free/busy schedules,
1.29 +there may be no urgent need to adopt relational database technologies,
1.30 +particularly as each user's data should remain isolated from that of
1.31 +other users, and thus the volumes of data should remain relatively small
1.32 +if managed well enough.
1.33 +
1.34 === imipweb ===
1.35
1.36 Most of the `imipweb` package is concerned with the display of calendar
1.37 @@ -138,24 +150,6 @@
1.38 Web page, interpreted by the program, written back to the form, all
1.39 without losing information.
1.40
1.41 -=== imip_store ===
1.42 -
1.43 -The `imip_store` module provides the basis for calendar data persistence.
1.44 -From the very start, the nature of data organisation for calendar users
1.45 -was centred on the storage of each user's free/busy records, since the
1.46 -priority was to generate such records from messages exchanged over e-mail,
1.47 -and the use of plain text files was chosen as the simplest and most
1.48 -transparent approach. Beyond this, the need to retain calendar objects
1.49 -arose, and thus a [[../FilesystemUsage|filesystem-based approach]] was
1.50 -cultivated to manage such data.
1.51 -
1.52 -In the future, other persistence mechanisms could be supported. However,
1.53 -aside from performance concerns around access to free/busy schedules,
1.54 -there may be no urgent need to adopt relational database technologies,
1.55 -particularly as each user's data should remain isolated from that of
1.56 -other users, and thus the volumes of data should remain relatively small
1.57 -if managed well enough.
1.58 -
1.59 == Localisation ==
1.60
1.61 The traditional [[https://www.gnu.org/s/gettext|gettext]] mechanisms for