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.

Using dated mailboxes
Using an archive folder
Using topical archive folders
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:

implement named configurations, per the wishlist
declare that if the executable file name of nPOPuk contains a hyphen, that all text between the hyphen and the .exe is used as a configuration name, for the named configuration idea in the wish list. If such a named configuration does not exist, the user is given a choice of all the named configurations in the list, and an option to create the named configuration that matches the name from the executable program. If there is no hyphen in the executable file name, then the configuration named "base" is used. If the hyphen is immediately followed by .exe, then the option to create the matching named configuration could be omitted.
nPOPuk.ini will still live in the same directory as the executable program. However, if it contains an section [Redirect] containing an entry inifile=pathname\filename then that specified location is used (error if not found), replacing the data directory with pathname, and the inifile with pathname\filename.
nPOPuk.ini is enhanced with AddressBookFile=pathname\filename option. This allows a single address book file to be used for "live" and "archival" folders. It also allows different address book files for different named configurations, which could be handy for some folks. If blank, the address book file defaults to the Address.lst in the data directory.
nPOPuk.ini is enhanced with DataDirectory=pathname option. This allows different data (mailbox) directories for different named configurations (a bunch of "archival" data directories could be configured).

(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.

Mailbox/ Add could have a 4th bullet: access savebox. The prompts would be the same as import savebox, but:

the savebox would not be added to nPOPuk.ini
If the savebox is deleted, the file that was accessed would not be deleted
in this way, an archival savebox could be accessed without switching configurations

Mailbox/ Add could have a 5th bullet item: access savebox directory. The prompts would be similar as import savebox, a directory instead of a file would be selected.

all files name *.mbx would be added to the current list of mailboxes (if mailbox folders are implemented, perhaps to a new mailbox folder)
if the savebox is deleted, the underlying file would not be
in this way, all the saveboxes in an archival directory could be accessed without switching configurations

nPOPuk.ini could be enhanced to specify certain saveboxes or directories of saveboxes to make available at initialization time. These would not be loaded initially, even if Load all mailboxes at startup is specified.

This could complement or contribute to the implementation of folders of saveboxes
some technique for selection an interesting savebox, other than a single drop-down list, is probably required (perhaps cascading menus?)