Re: sieve, and header_t's api

[Alain Magloire]

> > 
> > - There is no real protection in C, you just (char *) cast and
> >   write to the buffer, which may change the offsets of the parsing
> >   and the next header_get_value() will go to "lala" land.
> 
> You can ALWAYS cast in C, but then its your fault.
> 
> *((char*)message_t) = 'a'; //... ;-)

8-)
Do not why but I could not stop laughing 8-) ... it was so unexpected
as an argument. 8-)

> 
> > > I guess that I can do this means that the API is ok, but it seems like
> > > such a general purpose thing, that I'd like to maybe clean it up, and
> > > sell it as an adapter to wrap around header_t.
> > > 
> > > create_header_cache(header_cache_t* ch, message_t m);
> > > header_cache_get_field_values_p(header_cache_t ch, const char* name, 
> > > const char*** values);
> > 
> > Looks cool/interesting.
> 
> Ok, hopefully I can wrap it up nicely, I'm still prototyping now.

Thinking about it why not take over of the entire object, since
header_t suppose to be a class that you can overload all the
functions/method.  You should be able to "inherit" from it i.e.
polymorphism.

cache_header_create (header_t *ch, message_t m)
{
        struct my_private_data *owner;

        header_create (ch, owner);

        // Overload the differrent methods.

        // Take over _get_value
        header_set_get_value (ch, owner);

        // Take over _get_field_values ()
....
}

Then you got a special "header_t" that is caching the data.
hmm ... I feel that I'm missing some of your points though.

> > > Quick question because I'm lazy: what does IMAP do when you ask
> > > for the "received" fields?
> > 
> > It returns the "entire" received fields, in one block.
> 
> Sensible and useful.

8-)
Unfortunately, because of the way the header_t is done, maiutils/imap4d
has a different behaviour, where UW-imap returns:

 Received: from spock2.ECE.McGill.CA (address@hidden [132.206.1.2])
        by qnx.com (8.8.8/8.8.8) with ESMTP id JAA21691
        for <address@hidden>; Tue, 16 May 2000 09:15:27 -0400
 Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
        by spock2.ECE.McGill.CA (8.8.8/8.8.8) with ESMTP id JAA24089  


 Received: from spock2.ECE.McGill.CA (address@hidden [132.206.1.2])
        by qnx.com (8.8.8/8.8.8) with ESMTP id JAA21691
        for <address@hidden>; Tue, 16 May 2000 09:15:27 -0400
 from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
        by spock2.ECE.McGill.CA (8.8.8/8.8.8) with ESMTP id JAA24089  


sigh .. I think this is a bug, although it is conforming both
to RFC8222 and to RFC2060(IMAP) But somehow I don't thing
this is good ..  The approach was to let header_get_value()
coalesce the fields, so :
 To: address@hidden
 To: address@hidden

Will be return like "address@hidden address@hidden".


> Btw. The envelope_t doesn't seem to give the smtp envelope information
> as I thought it would, just From and date (what shows up in mbox, I
> think).

No not really, for the on-disk mailbox the from/date envelope
maps to the "From " separator of the message in mbox format.
For IMAP it maps to the "Sender" and imap INTERNALDATE command.

> There's an optional "envelope" feature that sieve can provide
> that alows filtering on the smtp "rcpt from" and "mail to" dialogs.

8-)
I think you mean "Mail From" and "Rcpt To:".
Sendmail usually passes the "Rcpt To" to the delivery program(MDA)(sendmail.cf)
usually to /bin/mail or similar.  The MDA will use the envelope
from for the message separator on Unix/Mbox "From ".

> That info isn't available, at least portably, is it?

No not really, for example maildir(qmail), mh, etc ... does not use it.

> Don't some smtp receivers put it in the mail before storing it to disk?

Not portably, it may be pass by the MTA(sendmail) to the MDA(/bin/mail) but
the MDA can do whatever with it.  And not all MTA's will pass it, for
exemple I'm not sure what qmail is doing with it.

> p.s. And the "path" scheme only works with full paths, which is kind
> of cheesy, I'd like to make it work for relative paths as well, I
> guess I can look at the _is_scheme memthod? I have to look into this,
> I'll be pretty unhappy if I can't sieve "~/mbox"...

8-), "~" is a shell expansion mechanism.  If you do
# cd mailutils/frm
# MAIL=~/mbox ./frm
...
It will work, because the shell will do the expansion for you.

But Jakob and Jeff wanted someway to let a sys admin set the default
mail spooldir base on a user/system basis.  So they came up with

        mailbox_create_default (mailbox_t *, const char *);

Where all sort of system dependent things are done, like :
 mailbox_create_default (&mbox, "sam");

could open /etc/mailutils.conf and search for "sam" and the path of
your mailbox
--- /etc/mailbox.conf
 sam = imap://host.name.net/INBOX # redirect user sam elsewere.
----

So yes, "~" or "~sam" can be implemented quite easily 8-).

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!