mailutils2 framework (was C/C++)

[Sergey Poznyakoff]

Bonjour,

> Alright then, lets view it another way:  I think we all agree
> on the need to have a clear lower level API to talk to the
> underlying mailbox formats.

Sure.

> Now comes the framework, that API to talk transparently to all of them,
> in C it is cumbersome and the language gets in the way, for example
> message_set_header() or mailbox_set_xxx this, mailbox_get_xx that
> there is no real inheritance, so we have end up with a bunch
> of _set/get_ calls, it can get messy especially when something
> wrong happen, in the lowest level(This is were sometimes, I crave
> for a good C++ throw 8).

Yes, I understand this. In such a complex system as mailutils is, a
mechanism like throw/catch would be very handy. It can be implemented,
by the way. The only difficulty that I see is that after each error
checking and before returning to the higher level function, we should
take care about freeing some memory. This could be facilitated by
building a common wrapper on top of malloc/free calls, which would
link all allocated blocks into a singly-linked list (eg: palloc in
Apache and proftpd). Then the top-layer call could take care about
freeing all allocated blocks at once. By the way, imap4d/search.c
works this way, it allowed to throw error conditions at every level
of its recursive-descent parser without worrying about memory.

> What do you see we can do in term of framework (mailbox_t/message_t,...)
> for the next step? (of course the next step is not tomorrow if at all 8)

I guess we'd better put it: 'the next step is after release' :^) By
the way, any preliminary date?

I like the vtable approach the new mailbox2 is built upon. I guess
it will make it much more flexible than the current one. The mailbox2
has now 19302 lines total, and I believe it is time to try linking
some simple applications against it and see how it works. I'll
try to do it this weekend. this should give us a fuller picture
of what we have now and what we still need to build.

Regards,
Sergey