Re: RFC mailbox interface

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

Hi,

On 2001.11.08 23:05 Magick wrote:

> open mailbox
> close mailbox
> create mailbox
> check mailbox
> sync/commit mailbox
> lock/unlock mailbox
> 
> get message
> get headers
> get body
> add message
> delete message
> update message
> 
> Where a message, headers or body is just a char array. The processing of
> the message is a
> totally separate action.
> 
Well, there should really be some processing done even at that level, and 
from the start. I would propose to parse the headers into an array of char 
with \0 delimiting each header and \0\0 meaning end of list. That would 
save all of us a lot of line-ending scanning. It would also make it easier 
to extract such things as message-id from the message at the lib level.
If IMAP will be handles correctly this time around, it means we would need 
a means to determine if a message is already on the server. The server will 
assign UIDs to the messages, but those are meaningless without context and 
may be invalided by the server at any time between sessions.
Assigning a message id to every message that doesn't have one would allow a 
scan of only the headers to resynchronize an offline storage with an IMAP 
server that has changed UIDs.
It would also mean that a message, copied from an IMAP server at some time 
in the past could be identified as still being on the IMAP server just by 
scanning local storage. If it already there, and hasn't been edited since, 
the already stored copy of the message could be copied by server-side 
commands instead of re-uploading the message again.

Also, the lib should natively support copy/move message in such a way that 
server side copy/move is used whenever possible. That means having source 
mailbox data tacked onto every message so it can be determined if a message 
will be copied from one folder to another on the same server.
Generally, data movement between machines should be kept to a minimum. If 
local IMAP shadowing is used, you may also want to think about having a 
function that returns mailbox TOCs in sorted sequence, on various fields. 
This would make it possible to offload sorting to servers that support it 
and to use the local shadow mailbox more efficiently for that purpose. The 
local shadow mailbox could even be an indexed or hashed database, making 
this the fastest IMAP lib ever.
I was thinking about this type of lib myself, but I can't find the time to 
actually do it. I had mapped out a similar API, but oject oriented.
However, I think that callbacks would confuse the issue to no end, so I 
didn't go any further in that direction.
A simple, robust API to efficiently manipulate mailboxes of any format 
would be a nice thing to have. Internally, you may want to structure it 
using tables of function pointers, so the lib can easily be expanded. As a 
matter of fact, I would probably have it load a shared lib for each mailbox 
type, using dlopen().
Then you would need some more calls to define the interface, like 
get_supported_formats and get_feature_mask, etc.
That would be neat, because some may want to write mailbox interfaces for 
it that use, for example, SQL databases (I would), or even interface with 
MAPI for those unfortunates who have to contend with MS Exchange servers 
without IMAP support... I did have an idea about those, too. Use a small 
windows-based server program that uses sockets to communicate with the unix 
world and uses MAPI.DLL, run it under WINE and, voila, access to MS 
Exchange is possible.
Well, taht's for later, anyway, but it would be easier if there was an 
extensible interface for mailbox handlers.

> Further was i planning to use as little as possible from glib, so no glib
> object or signals. Making it easier to separate the functions from Balsa.

Yes, and also easier to use them in non-graphical, non-gnu environments. I 
think, the first lib of this kind that really does all it's advertised to 
do may well become the standard for mailbox access under *nix. The more 
generally usable, the better.

> Optimizations like analyzing headers when scanning mbox files, are planned
> for a later stage.

See above, I would recommend parsing them from the start, it's easier than 
hacking that in later.

> I'm totally open to a different design. So if you have any comments or 
> know
> of mailbox libraries to look at or use: mail me or the list.

Well, that's my $.02

> This NOT about the implementation, just about how to interface with the 
> mailbox!

Well, it touches on the implementation now, just because the interface is 
related to that... form follows function, you know? :)

Melanie