Ultimately, the client database is a Sqlite database that can be "hacked". I used the approach of creating replica tables for the three main tables (history_item, history_message, and history_participant) with "_full" appended to the names. I then created INSERT and UPDATE triggers on the main tables to copy their data into the _full tables. That retains complete history from then on in the database. It just will not show in the GUI. The trick is then getting at that history in a user friendly way. The approach I used was to create a command script that ran extraction sql to convert the conversations into HTML files per conversant. I'm an Agent Ransack fan, so I then launch Agent Ransack on that folder to easily scan the resultant HTML files. If you don't have, and don't want to install, Agent Ransack, I default to launching an explorer window to that folder. You can then just double click the HTML and review/search that conversation.
An install requirement is Sqlite3.exe, the command line interface for Sqlite on which the Jabber history database file is built. I created the attached command script to perform the install. Sqlite3.exe can be obtained from https://www.sqlite.org/download.html. Download the "command-line shell" program under "Precompiled Binaries for Windows Runtime". This is a Windows solution. Tested on Windows 7, but should be Windows 8 and Server 2012 compatible as well. You could also port this to other OSes easily enough.
On a side note, I tried for a while to just retain the history and allow it to show in the GUI, but the GUI appears to be using a row limiter in the SELECT even if you prevent deletion (for those curious, I used an AFTER DELETE trigger to re-insert the row). I feel this solution is ultimately better, anyhow. For performance reasons the GUI results should be fairly limited. This is a best of both worlds approach.
Aaron
