Some hints for Mbox-module signature

Some hints for Mbox-module signature

[Oliver Bandel]

Hello,

some weeks ago I wrote a small tool to clean up mbox-files,
throwing out multiple mails of an mbox file (throw away
mails with same body).

Now I just had the idea to write a module that can be used
for more flexible programming then, not specialized to do
one certain task on mbox-files. So, wheras the mentioned program
only is used to throw away mails with same contents of the body,
the Mbox-module should be useful for many tasks, e.g.
selecting mails with a certain header-entry or body-contents
or something like that (maybe, selecting by size).

Here is, what tonight comes into my mind as a signature
for such a module (mbox.mli).


==================================================================

  type mbox_t
  type mail_t

  exception Could_not_write_mbox
  exception Could_not_read_mbox


  val Mbox.create :         string -> mbox_t            
  val Mbox.append :         mbox_t -> mbox_t -> mbox_t  
  val Mbox.read :           mbox_t -> unit            
  val Mbox.write :          mbox_t -> unit           
  val Mbox.write_force :    mbox_t -> unit          
  val Mbox.change_name :    mbox_t -> string -> unit


  val Mbox.rewind :         mbox_t -> unit         
  val Mbox.next_mail :      unit -> mail_t        


  val Mbox.match :          (string -> bool) -> mail_t -> bool 
  val Mbox.match_header :   (string -> bool) -> mail_t -> bool 
  val Mbox.match_body :     (string -> bool) -> mail_t -> bool
  val Mbox.grep :           string -> mail_t -> string list

  val Mbox.function :       (string -> 'a) -> (mail_t -> 'a)

(* iter/map/filter are preserving the order of the mails *)

  val Mbox.iter :           (mail_t -> unit) -> mbox_t -> unit
  val Mbox.map :            (mail_t -> 'a) -> mbox_t -> 'a list
  val Mbox.filter :         (mail_t -> bool) -> mbox_t -> string -> mbox_t

  val Mbox.sort :           (string -> string -> int) -> mbox_t -> mbox_t 
  
==================================================================


I think about using mbox_t and mail_t as an abstract type.

What about Mbox.function. Does it make sense to use a functor for the
functionality, or better using closures?
This function is intended to create functions that can be used with
Mbox.iter, Mbox.map, Mbox.filter.

Do you think this signature makes sense?
Are there functions to add?
Are there functions that seems to be unnecessary?

Do I really need rewind/next_mail?
My thought was: they can be used for
reading directly from the file, instead of 
reading in the whole file into memory, as
Mbox.read is intended to do.
But how to use such a function together with Mbox.iter/map/filter?
Should I add another function, so that Mbox.next_mail
(maybe "Mbox.next" is a sufficient name?) can be used together
with the iter/map/filter?
Functor? Closure?


If you have any suggestions, please let me know about it.

Thanks In Advance,
            Oliver Bandel

Re: [Caml-list] Some hints for Mbox-module signature

[Robert Roessler]

Oliver Bandel wrote:

> Hello,
> 
> some weeks ago I wrote a small tool to clean up mbox-files,
> throwing out multiple mails of an mbox file (throw away
> mails with same body).
> 
> Now I just had the idea to write a module that can be used
> for more flexible programming then, not specialized to do
> one certain task on mbox-files. So, wheras the mentioned program
> only is used to throw away mails with same contents of the body,
> the Mbox-module should be useful for many tasks, e.g.
> selecting mails with a certain header-entry or body-contents
> or something like that (maybe, selecting by size).
> ... 
> If you have any suggestions, please let me know about it.

Well, there is *one* thing I have always wanted from my mail system - 
and never seen implemented: I basically like to save *all* emails from 
and to anyone I have a business relationship with... BUT, sometimes 
these mails have large (hundreds of KB -> a MB) attachments, which are 
not really important.  The mail itself, along with a small "ghost" of 
the attachment (name and size) would be enough.

I use Mozilla mail which I believe does use the mbox format, along 
with its own indices which it builds as required.  So, if using a 
utility once in a while to surgically remove some attachments means I 
would have to delete the indices and let Moz mail rebuild them, no 
problem.

So, as long as your module and its interface make it "easy" to write 
my own Higher Order Mail Functions (HOMFs) to accomplish tasks like 
the above, I will be happy to test it for you. :)

More seriously, it does seem as if something like the tasks I outline 
would exercise a goodly fraction of your proposed functionality.

Robert Roessler
roessler@rftp.com
http://www.rftp.com