Re: RFC mailbox interface

[Magick <magick Linux-Fan com>]

On Wed, 14 Nov 2001 14:36:40 M . Thielker wrote:
> On 2001.11.09 20:56 Magick wrote:
>> 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.
>> 
> Agreed. It's not a matter of always having the headers around in parsed 
> format, only I would like to have one central place where parsing is 
> done, not several different ones. Also, it's more efficient to parse the 
> headers once and then search the list for the header you want than to 
> parse the headers again for every header field that needs to be etracted.
> 
Yes and that central place is a message structure in Balsa. It is a 
mailbox library not a mail-client lib, but it can become one. 
[ snip local storage for imap and virtual folders ]
For a local cache you can do 2 things use a standard mailbox, or role your 
own. Both can be implemented using the library.

>>> 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?
>> 
> Any type of callback. As soon as callbacks are involved, at least to me, 
> code becomes less readable. In order to find the functions actually 
> being called I not only have to look at the actual signal emission, but 
> I also have to look everywhere a callback is registered. In the end, I'm 
> not much wiser as to what list of functions is called in what order.
> I would not use any callbacks in this low level lib, leave callbacks and 
> gtk+ class structures to libbalsa! A message is an object, there are 
> methods to handle that object, they do what they should and then return, 
> no muss, no fuss. Straightforward, simple, efficient, that's what I 
> would like to see.
I was thinking about a callback when scanning mbox files, for direct 
header parsing. No other functions have come up yet, so there won't be 
many.
> 
>> 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.
>> 
> I don't really like single entry-point solutions, I prefer individual 
> functions, arrays of function pointers if C is used, or virtual 
> functions in C++. The qay I would code it would probably be thus:
> A structure defining the methods for dealing with a message of a vertain 
> type, consisting of an array of function pointers _only_. This would be 
> in a shared object loaded at runtime.
> Another structure containing the mailbox's data, including a pointer to 
> a structure describing the server connection, if any. There would be 
> only one such "server descriptor" for a iven server/username pair, so 
> the value of the pointer can be used to determine what server a message 
> is on.
> This structure (the mailbox one) would also have a pointer to the 
> structure with the function pointers and a list of pointers to the 
> contained messages.
> Finally, a structure containing message data. This would have a pointer 
> list to the mailbox descriptors referencing the message.
> This many-to-many linking ability would make virtual folders possible.
> 
> Deleting a message would, for example, access 
> (*message->mailbox->mailbox_type->delete)();
which would be written as
libmailbox_delete_message(message->mailbox, message->index_mailbox)
so you only have to recompile if there is a change....
> 
> In the case of a virtual folder, this would really do nothing but 
> removing the refrence. With a real folder, all the proper on-disk stuff 
> would take place there, too.
> A message that no longer has any mailboxes associated may be freed.
> A mailbox association is created through opening, insertion and virtual 
> folder shadowing. It is destroyed by closing the mailbox or deletion of 
> the message or the mailbox.
> 
> Am I making sense?
Yes, the virtual folders is a nice touch, I wasn't considering them.
> 
> 
>>> 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 ;-).
>> 
> Well, stealing the glist code would just about be all I would think we'd 
> need from glib. I would not use glib for that, just steal the code. One 
> less dependency to worry about.
Well, the glib dependency is not Hugh. glib only depends on libc and has a 
lot of compatibility options. There is also a lot more than glist, it has 
some nice string and memory functions.
> 
>>> 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.
>> 
> My idea: parse all the generally useful headers into the message 
> structure itself, into dedicated fields. It would look like this:
> 
[snip message structure ]
I like to keep it a bit more separate, libmutt has a more tight 
connection. It doesn't allow easy use of a lib like gmime.

> 
> 
>>> 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
> 
> Yes. I only brought that up to show what needs to be considered in the 
> initial design. Sometimes, you inadvertently close doors you will need 
> open later on. Going back to the drawing board with a finished piece of 
> code results in unmaintainable spaghetti code, or forces a complete 
> rewrite. Both are unacceptable.
If you look at my functionality listing:
open mailbox
close mailbox
create mailbox
check mailbox
sync/commit mailbox
lock/unlock mailbox

get message
get headers
get body
add message
del message
update message

you see that the functions are fairly separate. And i try to keep the 
interlocking small between different parts, like message and mailbox 
parsing.

Bart
-- 
Fingerprint = CD4D 5601 287D F075 6F96  6157 99F9 E56A 4B08 6D06