[Dovecot] Dovecot shared library to replace libc-client

[Timo Sirainen]

On 3.7.2012, at 8.53, Asheesh Laroia wrote:

> I see there is a dovecot shared library. I haven't looked into the 
> details, but here are things I'm interested in:
> 
> 1. Replacing libc-client's use as a client library
..
> I envision creating libdovecot-c-client-alike that is a set of headers 
> and a library that is API-compatible with (at least a subset of) 
> c-client. You can call that a "compatibility shim." Then e.g. php5-imap 
> could be given the path to those headers and the corresponding 
> libdovecot-c-client-alike library, and when it thinks it is linking to 
> c-client, it could instead link to the libdovecot-c-client-alike.

Yeah, that's a possibility. Although Dovecot's libraries are still more about the server side stuff than client side stuff, so it's possible that there are many important missing things. Also libc-client is commonly used to do IMAP access and Dovecot's imapc backend is still lacking quite a lot of that functionality.

> This might be convenient if you want to limit how much of a public API 
> is presented by the current "dovecot.so" that gets installed in e.g. 
> /usr/lib/dovecot/. The compatiblity shim could have a small API, and if 
> you don't want provide ABI guarantees within dovecot.so, the shim could 
> dlopen() dovecot.so rather than link to it.

I'm still not ready to give ABI or even API guarantees to libdovecot.. There are still several important large changes to do and I don't really want to keep a ton of ugly backwards compatibility stuff just for external users of the library. Also another potential problem is that libdovecot.so doesn't use a global namespace prefix for all of its functions, so linking it with php could cause symbol name conflicts (especially md5_*, sha1_* and such could cause trouble, like they already have caused with libmysql).

Once Dovecot becomes more "finished" (a few years?) I could consider API/ABI guarantees.. Of course nothing prevents anyone else from distributing a (patched) libdovecot already that actually does give some ABI guarantees. I just don't want to spend time on it. And v2.1 -> v2.2 -> v2.3 etc. transitions are going to be large changes.

> 2. Use of Dovecot shared library within alpine, embedding the imapd
> 
> Right now, the mail client "alpine" embeds a copy of the UW IMAP 
> source. It uses this when accessing local mail spools, for example.
> 
> If Dovecot's IMAPd were available as a shared library, perhaps with a 
> c-client-like API, (although not necessarily -- it would be feasible to 
> upgrade alpine to a different API), then alpine could use Dovecot's 
> mail drivers directly.

I wonder if it would make any sense to for Alpine not use libdovecot API directly but rather talk IMAP protocol to Dovecot code (maybe running in a separate process)? The Dovecot configuration could be passed pretty easily from Alpine code without requiring any extra config files.