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

[Sergey Poznyakoff]

> > will work with 1.4 but will not with 1.6. Is there any portable way that
> > will make it work with both versions? 
> 
> Yes, but you have to switch to an approach that's more like the 1.6
[..lots of good stuff skipped..]

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? Current snapshots of 1.6 install only
guile-snarfer, guile-doc-snarfer is not installed and this means that
package developers will need to supply their own versions. Mailutils
does provide both snarfers with the package but it would be much better if
they were available along with other guile binaries.

> Right, I'd seen that, but I wanted a way to get the actual text of the
> message, unsplit, *unre-ordered*, and unaltered, from the start of the
> message up to the body delimiter.

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

> >         (let ((port (mu_message_get_port message "r" #t)))
> >            (do ((line (read-line port) (read-line port)))
> 
> OK, this might do the job if there's a general way to know when I've
> run off the end of the headers, i.e. for mbox it's \n\n, but in
> rfc822(?) it's CRLF CRLF.

For local mailboxes (i.e. for mbox, mh, etc.) this will always be
\n\n. For "remote mailboxes" (imap://, pop://) the notion of a "message
stream" is still not precisely defined. In their case (read-line) will
currently fail...

>  Basically what I'm thinking of is
> (mu-message-get-header-text msg) and (mu-message-get-body-text msg),
> or perhaps (mu-message-with-input-from-headers msg thunk) and
> (mu-message-with-input-from-body msg thunk).

That would be interesting. Again, there are two cases:
for local mailboxes (i.e. mbox,mh,etc.) this can be implemented on top
of mu-message-get-port (from scheme), or message_get_stream (from C)
(possibly with some heuristics to compensate for \n\n vs. CRLF-CRLF
incertainty). However, for remote mailboxes, (mu-message-get-headers)
seems to be the only way, given that in this case we cannot guarantee
the data are received unordered.

> Basically I wanted to be able to do something like this:
[..lots of interesting stuff follows..]

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

Regards,
Sergey