Re: sieve, and header_t's api

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> Those were the reasons, why I thought we could not use parse822()
> inside header_t.

Yes.

> The allocating ones are convenient functions.  Should we have the same
> for address_t also?
> 
> address_aget_email()?

Probably.

> > I need a header_t API that passes me back pointers to const data
> > that has a lifetime of the header_t. Since there isn't one, I
> > have to pull all the header field values out of header_t, and put
> > them in my own data structrure, and then query it for header
> > values. Basically I build a cache of the header field's and pass
> > back pointers into that cache.
> > 
> > I wouldn't even mention this, except that it appears that inside
> > the mailbox API, the mailbox is doing the same thing...
> 
> The dangers here of exposing the header internal, in that case the
> entire buffer, are:
> 
> - 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'; //... ;-)

> - when calling header_set_value (), this function for it needs
>   can decide to realloc() the entire buffer (free()/malloc())
>   which means that the pointer (const char *buffer) that the application
>   is holding is simply gone and will cause a crash.

This convinces me absolutely. The data isn't necessarily constant,
which I was thinking it was.

> > 2 - write a cache_t class, that stores name/value pairs, where there
> > can be more one than one value per name. Sieve had this, and I'm
> > cleaning it up a bit. Using it I'm implementing an API like -2- suggests.
> 
> I actually like cache_t(-2-) because I will have, in the future, to come up
> with a "cache mailbox" implementation.

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

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

> Yes, I would have like to keep the sorting/threading outside the mailbox
> and not to bloat this object to much and rather have a new object
> sorting_t/threading_t or something.  But unfortunately, there are
> an extensions to the IMAP rfcs that describe sorting/threading 8)
> 
> http://www.imc.org/draft-ietf-imapext-thread
> http://www.imc.org/draft-ietf-imapext-sort
> 
> But we could have this
> mailbox_get_sort (mailbox_t, sorting_t *);
> 
> Which return a sorting/threading object hat the concrete mailbox can
> implement/overload.

Ah. Good idea.

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). There's an optional "envelope" feature that sieve can provide
that alows filtering on the smtp "rcpt from" and "mail to" dialogs.
That info isn't available, at least portably, is it? Don't some
smtp receivers put it in the mail before storing it to disk?

Something to think about.

Sam

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

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)