On Tue, 3 Jul 2012, Timo Sirainen wrote:
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.
Timo, I appreciate the super speedy response!
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).
Yeah, I totally understand your desire to not make backwards compatiblity
a goal of the project.
Interesting point about the global namespace prefix. Is this something
you'd be willing to reconsider, and start using a global namespace prefix?
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.
Yeah -- what I think is the most sensible, at the moment, is to distribute
a small shim that has reasonably-tight dependencies to dovecot itself, and
so when you upgrade dovecot, you probably have to upgrade the shim. So it
proxies away the instability in dovecot, and provides a small, stable
API/ABI.
That's something that it seems you might not be interested in, but I
wonder if I can convince you otherwise.
If not, I might try convincing others to write it, but I'm hoping you
might since you are so great! (-:
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.
That's my fallback plan at the moment, yeah. It seems like more work,
though, but it has some serious tidiness possibly going for it.
-- Asheesh.
