[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rob Browning
Subject: Re: mailutils questions - features and guile (perhaps the wrong list)
Date: Thu, 08 Aug 2002 09:27:10 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu)

Sergey Poznyakoff <address@hidden> writes:

> Of course, it would be of great interest. Actually, libmu_scm was
> planned as such a module. The only thing it lacks is module
> initialization function. I was reluctant to implement it as a module,
> since guile 1.4 and (would be) 1.6 have different conventions on init
> functions. Using
>       scm_register_module_xxx ("util mailutils", init_mailutils);
> 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
approach.  Basically you have to have a mailutils.scm file, and that
file will define the module, load the shared library, and then export
the relevant functions.  So you'd have something like this (off the
top of my head):

  (define-module (mailutils))

   ((or (string=? (version) "1.3")
        (string=? (version) "1.3.4"))
    (dynamic-call "init_mailutils" (dynamic-link "libguile-mailutils-v-1")))
    (load-extension "libguile-mailutils-v-1" "init_mailutils")))

  (export mu-address-get-personal)
  (export mu-address-get-comments)

The -v-1 isn't required, but it's highly recommended for now.  That's
because you can't ask the underlying libltdl for a specific version of
a given lib.  Encoding the major number into the lib name fixes that
and means you won't have .la file name conflicts if/when you release

Also for now, the library should just go into the standard libdir,
i.e. /usr/lib/libguile-mailutils-v-1.so.1.0.0, etc.

> As you may notice libmu_scm and guimb stuff is still oriented to 1.4,
> I was planning to clean it up when 1.6 finally appeared (by the way
> when is it going to be released?)

Probably about two weeks after I can upload 1.5.7.  1.5.7 is ready to
go, but none of the upload areas are available right now.  I was ready
to upload about a week ago, but alpha.gnu.org is down.  I'll probably
be uploading to an alternate area today or tomorrow after mvo checks
on one more thing.  Then if there are no agreed-upon release critical
bugs within about two weeks, 1.6.1 will be uploaded/announced.

> There are several ways to get the message headers from Scheme. First,
> you can use mu-message-get-header to return a particular header, e.g.:

> Second, you can get a list of all (or a subset of all) headers, using
> mu-message-get-header-fields, e.g.:

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.

> Finally, you can get a port associated with the message and thus
> access it in the row mode, e.g.:
>         (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.  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).

> Yes, it is possible. For example, sieve module guimb/scm/reject.scm
> creates a multipart message from scratch and sends it to to the remote
> party.

Basically I wanted to be able to do something like this:

  (let ((hdrs (mu-message-get-header-text msg))
        (body (mu-message-get-body-text msg)))
     (string-append "insert (headers,body) into messages VALUES ("
                    "'" (esc-str-for-sql hdrs) "',"
                    "'" (esc-str-for-sql body) "')")))

... then in another program or file or whatever -- basically much
later ...

  (let* ((hdrs (get-header-string-for-message-in-database-with-uid id))
         (dummy-msg (mu-make-message-from-header-and-body hdrs ""))
         (msg-from (mu-message-get-header-fields dummy-msg '("From"))))
    (do-stuff-with-msg-from msg-from)

or something equivalent.  The key is the ability to manufacture a
message with something like mu-make-message-from-header-and-body, so
you can then use the normal mu utility functions on the parts.
Something like this would be fine too:

  (mu-string->message (string-append headers "\n\n" body))

as long as there was clear documentation about what format (rfc, mbox,
etc.) the string had to be in...


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]