On 3.7.2012, at 9.18, Asheesh Laroia wrote:
>> 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?
Dovecot in any case will have many different prefixes (I don't want to change
ALL functions to begin with the same one), but there is one that is somewhat
commonly used already: "i_" which originally indicated "irssi library" :)
dovecot-2.1/src/lib% grep '\bi_' *.h|wc -l
175
Much of the rest of the functions in lib/ could be prefixed with "i_" I guess.
But there are several annoying problems, such as t_ prefix is also commonly
used in many places and I don't want to remove them (but they probably won't be
a real problem either). Then there's i_stream_*() for input streams vs.
o_stream_*() for output streams. But for some of the clearly unproblematic ones
the i_ prefix could be added, like for md5/sha/etc small and potentially
conflicting functions.
Also I think GNU ld supports some way of hiding all but the explicitly wanted
symbols from libraries, which would allow libdovecot to use all of its
functions internally without the danger of them conflicting with outside users.
But I'm not entirely sure how that works, maybe it needs to be done at linking
stage which won't be good for Dovecot binaries that link with libdovecot.
>> 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! (-:
The best I can do is that at some point in future (might still be 1-2 years) I
want to provide scripting language bindings for Dovecot APIs, maybe even allow
creating plugins with non-C languages. Those APIs would then pretty much have
to be frozen so that they don't break. Before that I need to do a few more
larger API breakages to support some missing things.
>> 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.
You could have Alpine keep the libc-client code and simply use it to connect to
local Dovecot via IMAP protocol. All of the mailbox access would then go via
Dovecot. I don't think it would be much work, mainly you'd need to create
"libc-client mail storage configuration" -> "Dovecot settings in key=value
format", fork a new process, put the settings to environment, exec imap and
that's about it.
