On Thu, 18 Jun 2026 at 11:28:37 +0200, Oswald Buddenhagen wrote:
> you are welcome to attempt factoring out imap_auth_*, but i have a suspicion
> that such an abstraction won't pull its weight.
I have begun doing so, and so far it appears to be straight forward; the
process boils down to configuring a few options (e.g. are we over TLS?)
and finding shared mechanisms. The rest is mostly moving over the
current code (for the Cyrus implementation at least).
I have noticed the SASL-related error messages are too fine-grained to
be kept in drv_imap.c, but would be duplicated if moved to each
sasl_*.c. So I've added a sasl_common.c file to house small functions,
such as specific error messages, which can be called by either SASL
implementation.
> > I am one of the aforementioned users who perfers the license of GNU
> > SASL over Cyrus SASL,
> >
> try it with #ifdefs first. these will show directly where abstractions would
> need to be introduced,
I'm not yet knowledgeable enough on the GNU SASL API to do so, which is
why I wish to build the abstraction prior to adding another SASL
implementation. Though I have skimmed the docs and the API appears
similar enough to fit the abstraction.
P.S. For a patch, would you prefer it be based on master or master-next?
Since it interacts with ensure_password(), the patch would be different
for either.
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
