Re: Looking to share cost of MHonArc customisation

[Earl Hood <earl@xxxxxxxxxxxx>]

--- J C Lawrence <claw@xxxxxxxx> wrote:
> > Further to my previous email, I'm now looking to get some
> > customisation of MHonArc done professionally to add a required
> > feature. The work would involve adding an option to a resource file,
> > whereby the amount of disk space that an archive occupied could be
> > limited. 
> 
> This doesn't inherently need a modification to MHonArc.  Just wrap your
> call to MHonArc in a script which runs `du` against the target
> directory, adds in the computed size of the current message and then
> does The Right Thing.

But what exactly is "The Right Thing"?

Various solutions exist to get the size of messages outside of mhonarc
(attachments and a little twist, but is manageable).  However, the trick
is how to tell mhonarc to delete older messages until the total archive
size is below max bytes size.  I do not see an efficient solution to
this that does not require hooking into mhonarc itself or performing
your own bookkeeping of messages (duplicating some of what mhonarc does).

As always, there is more than one way to solve the problem, it is
just a matter of what is the best solution based on usage requirements.
Processing outside of mhonarc itself is doable, but is less efficient.
If mhonarc tracked byte sizes of converted messages (along with their
attachments), it can easily auto-remove older messages, when needed,
and do it during a single update operation.

BTW, external-based processing would may need to deal synchronization
issues.  I.e. Some form of external locking is needed on the archive
to avoid multiple processes from accessing the archive.  Something
like Procmail's lockfile could be used to manage this.

--ewh