Re: mailutils questions - features and guile (perhaps the wrong list)

[Rob Browning]

Sergey Poznyakoff <address@hidden> writes:

> Thanks, I will surely implement it so. There is also another
> question. I have posted it to guile-devel some time ago, but it seem
> to remain unnoticed. The queston is: will guile provide full
> snarfing support for the developers?

Evenutally -- probably.  Right now, maybe not.  My impression is that
while we want this kind of functionality to be generally available in
the future (at least I do), we want to provide it with good
documentation and well thought out semantics.  This is a topic I'm
definitely planning to pursue in the 1.7 tree, but I'm not sure that
anything more will make it into the 1.6 tree.

Note though, that the next stable release, 1.8, should be out *much*
more quickly than 1.7 was -- we already have a number of important
changes queued up that would justify a 1.8 release (some pretty
interesting ones too like GMP integration, starting with bignums), so
there shouldn't be another long hiatus.

> Mailutils does provide both snarfers with the package but it would
> be much better if they were available along with other guile
> binaries.

For now, I think you may have to just keep doing that, but in the not
too distant future, guile should have an "official mechanism".

> I see. Note, however, that for certain mailbox formats it is
> impossible. For example when accessing imap:// or pop:// mailboxes
> the headers are collected as a result of communicating with
> corresponding servers, thus the underlying library cannot guarantee
> it receives data "unre-ordered".

Ahh, right.  For these "special purpose" manipulations, I was
definitely thinking of cases where you have direct access to the
message text

> Looks promising. Are you planning to implement this on C level or
> on Scheme level?

Heck, I'm not even sure I'll finish it, and for the moment I switched
to perl and perl's Pg and Mail::Box::Manager modules for some
comparative experimentation.  On the guile side I'd be likely to use
mailutils and guile-pg, and in emacs (see below) perhaps pg.el.

In the long run I've been toying with the idea of a postgresql mail
repository with a bit more sophistication than you usually have with
mail.  I was also investigating the feasibility of an nnsql gnus front
end to the hypothetical repository.  Accordingly, I wrote a little
dummy (very trivial) backend just to see how hard it might be.

I was playing with mailutils, etc. as tools to slice up the original
messages in various ways so I could cram them into the DB.  I had
asked about splitting the message header from body because I was
considering storing the headers and body separately, i.e. with this as
the main content table:

 * messages table
   (unique-msg-num message-id header-text body-text)
   ;; msg-num is a sequence -- monotonic increasing, values never re-used.

There would also be a number of other tables, some storing the split
out headers for fast searching, group membership, etc., but you'd
always be able to reconstruct the exact original message by
concatenating the header and body fields in the table above.  I don't
really know how well postgresql might handle extremely large numbers
of message bodies, but I've got some giant archives I can use to find
out :> and you could always switch to keep the bodies outside the DB
if you needed do.

Again, who knows if I'll actually have time to get very far with all
this (or if it's even wise :>), but in the process I noticed some
things that might be interesting for mailutils.

Thanks again.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD