Re: sieve, and header_t's api

[Alain Magloire]

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

I was talking about this at work with Dave.  And we could actually do 
a mailbox caching mechanism which saves parts of the information to file
by using.

http://www.imc.org/draft-klyne-message-rfc822-xml

8-) The format would be XML.  For example, if we want to cache a mailbox
that is access remotely say IMAP, but you also want to minimise traffic
even if the server machine rebooted.  So every bit of information
is retreive is save on local file system as they are needed.  So for
example we just had a couple headers only for message 1 :

----- caching.emx
<emx:Message
    xmlns:emx='URN:IANA:namespace:email-xml:'
    xmlns:rfc822='URN:IANA:namespace:rfc822:'
    emx:content='cid:2@100Aker.org'>
    emx:mid='address@hidden'>
  <rfc822:from>
    <emx:Address>
      <emx:adrs>address@hidden</emx:adrs>
      <emx:personal>Sam Roberts</emx:name>
    </emx:Address>
  </rfc822:from>
  <rfc822:subject>
      Yellow submarine.
  </rfc822:subject>
<emx:Message>

--------------------

This overly verbose format will permit to reconstruct the message
even though you only have some pieces of it.

Toughts ?

--
alain