<<< Date Index >>>     <<< Thread Index >>>

Re: Build system



Hi,

* Enrico Weigelt [06-05-18 11:16:09 +0200] wrote:

I really like to get some steps further. Once the mailbox handling
is an independent library, people can write their own drivers/backends
for a lot of things, ie. RDF. This even gets better, if we also have
posting stuff in this framework, so its easy to plug in adaptors for
certain forums, nntp, etc, etc.

Beware: it's not _that_ easy. There already is the vvv.nntp patch and while mail and news article formats are close, that patch is a mess. It requires _far_ more than just a mailbox driver. For example, mailbox drivers are used for incomming messages... but once you have RDF and feeds and want to post commits, you also need a different output driver (like libcurl and HTTP put or whatever) (and a framework for that).

I really suggest looking at vvv.nntp for areas you need to look at and keep in mind that it violates standards in many ways, i.e. it's not even complete (the article formats for mail and news differ slightly though they're pretty even).

Of course this is an larger project, and I suggest the following way:

1. define an clear API for the client side of this frameork

Now we already have the mx_* functions defined in mx.h. Besides a few places (like in buffy.c the code checking all mailboxes for new mail) only the mx_* functions are used.

2. wrap around mutt's current mbox code with this API and put it into an separate library.

All drivers roughly implement the API right now. Well, not on their own meaning in mh.c, mbox.c and such, but the code is in mx.c and "only" needs to be separated by moving it.

3. rewrite mbox.c to sit on top of this API (conditional build)

After moving code from mx.c to (e.g.) mbox.c this would be trivial.

I'd like to design the interface of this new mbox library in the
spirit of directfb's interfaces. This seems quite stable and robust
to me.

This is not really easy as there're many other parts getting in your way very quickly. For example, if the mailbox drivers were in a separate library, we'd need a way to handle config options used in there, configure that library at run-time with things like error reporting callbacks, etc.

  bye, Rocco
--
:wq!