Re: RFC mailbox interface

[Magick <magick Linux-Fan com>]

On Thu, 08 Nov 2001 23:35:42 M . Thielker wrote:
> 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
move/copy message from mailbox 1 to mailbox 2
>> 
>> 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.
We can do this for the 'get headers' function, the question is than how to
handle multi line headers. The easiest way is to leave the line-ending in
place and just treat it as white-space.
But for the 'get message' function, having it as one big string makes it
possible to hand it over to for example gmime. I think that one big string
is kind of the natural state of a message, because that is how it is
transfered.

[snip IMAP usage scenario]

> 
> 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.
So we need a function to move/copy message in mailbox1 to mailbox2. OK, I
think that is useful...

> 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.
This can be a useful function, but i think this is something for version
2.

> 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.
OO like C++ or like glib/gtk? Do you have your design digital, or want to
type it up? I'd love to have a look.

> However, I think that callbacks would confuse the issue to no end, so I
> didn't go any further in that direction.
Which callbacks did you had in mind?

> 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.
My idea is to have a single entry point for the basic operations. Added
with utility/optimization functions which can say: no i can't do that for
you, do it yourself. Like the IMAP sorting.

> 
>> 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.
Yes, something like libesmtp wants to be ;-).

> 
>> 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.
Well when you are reading/scanning an mbox file, you'll be reading it line
for line. My idea was we have a line why not pass it along to some
function which can then extract useful information about the message.
Information like Subject, Sender or Date. Maybe even message size, which
can than be given as a hint to the mailbox scanner.

> 
>> 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
And a welcome $.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? :)
Yeah, but not about stuff like keeping an index file for faster scanning,
but more focused on how Balsa will see the mailboxes
> 
> Melanie
Bart
--
Fingerprint = CD4D 5601 287D F075 6F96  6157 99F9 E56A 4B08 6D06