Re: RFC mailbox interface

["M . Thielker" <balsa t-data com>]

On 2001.11.22 10:56 Kenneth Haley wrote:
> Should the Message struct contain strings for list display and threading 
> instead of a getHeaders search function?
It should have both, I think.

> Does the API really need getAllHeaders, getBody, and getAll or would 
> getAll be enough and let the client seperate out the headers?
That would result in duplication of code that is best kept in a lib. Having 
it in the lib will give a single, well tested and robust function to do 
that, rather than having the app delvelopers reinvent the wheel. The lib 
needs to be able to parse headers anyway, so why not expose that 
functionality?

> Are the strings returned by the getX functions managed by the lib or by 
> balsa?
> 
By the lib. It will free any storage associated with messages and folders. 
All else would lead to madness.

> How about these?  The idea is to conserve memory with open/close being 
> used when opening and closing the message list.
> Folder->open creates the internal Message holding structure and returns 
> Stats.
> Folder->close frees the above
> Folder->check if Folder is open it updates the above else it just returns 
> Stats.
> 
Yes, that would be good for display purposes. Actually, I maintain a 
private patch for Balsa to give it the ability to gather stats on closed 
IMAP folders.......

> How about a second global function that return a list of acceptable 
> mailbox types?  Possibly a static array whose indexes could be used when 
> creating a new server.

Well, I had more or less that in mind when I wrote that other message, the 
one that got accused of describing Evo.

I think it should not be a simple list, though. I would like to have a 
dlopen() based mechanism to load backend support modules. That would 
require a slightly different configuration API.

Melanie