nPOPuk archiving techniques

There are several different ideas for archiving mailboxes below, that are possible to implement today.  They are described, and then a comparison chart of advantages and disadvantages is given.  In the notes of the comparison chart, speculative enhancements to these techniques, which depend on nPOPuk enhancements, are discussed.  It is not clear that any of these techniques are "best", and the enhancements all have other merits (also mentioned in the discussion), so it might be wise to consider implementing all the enhancements, depending on their complexity.  I leave it to Geoffrey to comment on code complexity issues for the suggested enhancements, not being personally familiar with the code.
  1. Using dated mailboxes
  2. Using an archive folder
  3. Using topical archive folders
  4. Using dated archive folders

Using dated mailboxes

Each mailbox FOO which grows too large can be archived as follows: select a set of older messages within the mailbox, right click, choose Move To, (New), and answer the prompts.  Name the new mailbox the same as the old mailbox, but with the date in some format (FOO-YYMMDD is recommended, for sorting purposes) appended to the name.  Loading mailboxes on demand is highly recommended when using this technique.

Using an archive folder

Setup: Make an archive folder, containing a minimal configuration of nPOPuk.  Running that copy of nPOPuk, import whole mailboxes from your main nPOPuk folder.  See here for complete process to use. 

Each mailbox FOO which grows too large, can be imported into the archive folder with name FOO-YYMMDD, and then all the messages deleted from FOO.

Using topical archive folders

Same as above technique, except that each mailbox, or small group of related mailboxes, is archived into its own archive folder.

Using dated archive folders

This technique archives and cleans all the mailboxes at once, based on total size.  When you notice the total size of mailboxes is too large, do File / Backup Files... and backup to a dated directory.  If, for example, your nPOPuk data directory is \email\nPOPuk, you might use \email\nPOPuk-YYMMDD for each archive folder.

Comparing the techniques

pros and cons descriptions (contributions and discussion welcome)
dated mailboxes
archive folder
topical archive folders
dated archive folders
all files available in main email directory, can be opened by main version of nPOPuk when needed.
PRO
CON
CON
CON
archive files clutter the main email directory, causing the drop-down list of mailboxes to grow large, and possibly scroll (5)
CON (2)
PRO
PRO
PRO
recent emails can easily be retained in main folders for access to current conversational threads
PRO
CON
CON
CON
low-frequency-of-use mailboxes have conversations scattered across many mailboxes, because of the frequency of archiving is determined by high-frequency-of-use mailboxes
PRO
PRO
PRO
CON
extra nPOPuk configurations must be maintained (4)
PRO
CON
CON
CON (1)
ease of archiving
PRO
CON
CON
PRO
ease of accessing archive
PRO
semi-PRO
semi-PRO
CON
one find operation can search whole topic history, if desired
PRO
PRO
PRO
CON
one find operation can search whole archive, if desired
PRO
PRO
CON
CON
Loading mailboxes on demand, instead of all at startup, is a requirement
CON (3)
PRO
PRO
PRO
Archive folders can grow large, straining the limits of small devices
CON
CON
semi-CON
PRO





count of PROs/CONs
8/3
6/5
5/6
4/7

Notes:

(1) You don't need extra nPOPuk configurations to create the archive, but you will need one for each dated folder that you wish to access later.

(2) The wishlist contains the idea of organizing mailboxes into groups or folders for easier management of large collections of mailboxes.  While this wishlist item was not created with the needs of archiving in mind, the implementation of it might alleviate this CON.  See also (5).

(3) It is not clear that this is a CON in any situation; but if it is, its use is only forced by the dated mailboxes technique, for the main copy of nPOPuk; however, the configurations of nPOPuk in the archive folders should probably all use the technique, but if using it is a CON, at least this is in a lower-frequency-of-use configuration of nPOPuk.

(4) Extra configurations are a pain to keep in sync with the main configurations.  Because of limits of PPC devices, each separate configuration of nPOPuk requires a separate folder, with a separate nPOPuk.ini file, and a separate instance of nPOPuk.exe.  Upgrading to a new version of nPOPuk requires (for safety) upgrading all copies in all folders, which is annoying to have to do.  The wishlist contains a request for multiple configurations of nPOPuk maintained in a single file.   While this wishlist item was created to address multiple environment issues, some discussion on the list regarding portability suggested using this technique with another file used to specify the configuration and the data directory. With a further tweak it could also address the issue of multiple data directories: The tweak would be the ability to specify, in the new file, a user prompt for the configuration name and (hopefully implicitly) the data directory.  Whereas the discussion on the list talked about one section with two entries (configuration name, and data directory path), to support multiple archive folders with one nPOPuk configuration (instead of one per archive folder), one would need to place in the initial configuration multiple sets of three entries... one set per archive folder, and allow choice.  Currently, the nPOPuk.ini and address book files lives in the data directory, but I suggest for convenience and avoidance of replicated data, that it be possible to place them in a separate location.  So the three items are (1) configuration name (2) directory containing nPOPuk.ini and address book (3) data directory (mailbox files).  This would allow using a single nPOPuk.ini (containing multiple named configurations) for both "live" data, and "archival" data.  And it would allow using only two copies of nPOPuk.exe ("live" and "archival"): the "live" copy would not prompt the user for a selection of configuration, but would have a particular one to use; the "archival" copy would prompt for choice of which triple to use, basically the choice would be of which archive is to use.  This could be reduced to two copies of nPOPuk.exe in one directory (saving the need for multiple copies of the SSL DLLs) if the name of nPOPuk.exe were correlated with the name of the configuration to use.  (This gives me the old AHA feeling).

Here is a summary of enhancements that could turn all the CONs in this row to PROs:
(5) Perhaps it would be nice to implement the ability to "access" a savebox from somewhere else, without really importing it... or maybe even a whole directory full of them... or maybe even several directories full of them.  Here are some ideas.