Re: mailutils2 framework (was C/C++)

[Alain Magloire]

> 
> 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.

Alright see comment at the end.

> > 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.

You could also do it with setjmp/longjmp and walking up the stack
but .. lets wait a while for this 8-) see comments below.

> 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.

the imap4d/search.c, always forget that I need to factor at the code
for a search_t so mailbox_t types can have a generic interface.

> > 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

and missing the same amount .. still in my repository, but will probably
never see the light of day 8-).

> 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.

Probaby the best approach is to do the low level stuff in regular C.
Support for  POP3, MBOX, MH, MAILDIR, IMAP, etc ..
In a "simple" C API, no funky,  stream_t, attribute_t, message_t etc .. 
Carte blanche to do whatever at this level, with a few restrictions:

- namespace: everything starts with mu_ prefix.  For example:
   mu_pop3_connect();
   mu_pop3_retr();

- standalone, If I only need pop3, I do not pull the entire lib.
  for example:
  cc -o pop3client *.o -lpop3


For example, if you want to do the MH, it will probably be easier,
no funkyness about how to save MH sequences in mailbox_t etc ..

We can always deal with the framework and C vs C++ vs java,
CMC vs MAPI and mailbox_t, message_t etc .. much much later.

my 0.00002$ canadian?